Building FORTRAN

[Ed Baunton]

I am trying to figure out the best way to support building FORTRAN code using bazel.  I have some queries about the general design of rules that came up after reviewing the existing documentation [1][2].  Some parts were not clear to me so please forgive any basic misunderstanding I might have; a github issue might be a better forum for discussion.

Initially, it seemed like I could simply write some rules with e.g. gfortran hardcoded as a basic implementation, however it seems like the use of a toolchain is more correct since there are many different FORTRAN compilers.  So in the simplest case, does it at least make sense to write a toolchain provider for FORTRAN? Is it possible?

Later, reviewing crosstool_config.proto which is currently dedicated to C/C++,  it seemed like it might make sense to extend that to support FORTRAN since they share similarities and often bundle together (e.g. you can actually feed FORTRAN code to gcc and it will pass it to gfortran); as well as the fact that they often are linked into the same executables.

Would it make sense to simply extend the CROSSTOOL specification to include support for a FORTRAN compiler? There is prior art in CMake for this approach

In the case of GCC, it knows to defer compilation of FORTRAN files down to gfortran when passed to it, so one could simply (theoretically) extend bazel to allow the .f and .inc extensions to the C/C++ rules (or create new rules that defer to the existing ones but restrict on the file extension). However that seems a little hacky and brittle and obviously break down once you extend beyond just gfortran/GCC.

Finally, is there anyone else who shares the need to build FORTRAN?

Ed

[1] https://docs.bazel.build/versions/master/toolchains.html

[2] https://github.com/bazelbuild/bazel/wiki/Building-with-a-custom-toolchain

[Austin Schuh]

Ah, fortran.  I've been building it for a couple years now.

http://frc971.org/content/2017-software at //tools/build_rules/fortran.bzl has our rules.  Not particularly exciting or elegant, but they get the job done and may help you get started.

Austin

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/c68eaed2-7009-4441-9dde-8af334bb09aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Xavier Bonaventura]

I was just wondering if anyone continued any progress on compiling FORTRAN with Bazel. I guess one would have to write rules_fortran if we do not want to pollute the C++ toolchain.
But as Ed Baunton said, it would be nice if we can reduce duplicity.

Xavi

[Austin Schuh]

We mostly gave up and stubbed out to f2c. See
https://github.com/frc971/971-Robot-Code/blob/master/tools/build_rules/fortran.bzl
for our latest. Finding well packaged fortran toolchains for cross
compilation got hard enough and we had a limited set of code we needed
to build which wasn't really changing.

The rules_cc sandwich should help a lot with this type of activity now.

Austin

> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/e9b33470-043f-4393-b6bf-39d5d0ceda31n%40googlegroups.com.

[Minseo Park]

I've been maintaining rules_fortran. It uses LLVM Flang, with prebuilt binaries distributed via a separate repo similar to how emcc binaries are consumed in Bazel Emscripten toolchain.

It works with CcInfo so Fortran and C/C++ targets can depend on each other. I borrowed some of the toolchain patterns from rules_cc and rules_rust.

Was able to compile netlib BLAS/LAPACK and pass their bundled test suites. https://github.com/miinso/rules_fortran/actions/runs/19954337246/job/57220391618

Still missing LTO support and sanitizers.

Minseo