Previously, Flang would assume that the platform that Flang is compiled on is the same platform that the compiled application is going to run on. This is obviously wrong and compileing the runtime separately is a step into making Flang support cross-compilation.
Even with just -DLLVM_ENABLE_PROJECTS=flang, a simple check-flang is going to continue to work, but not testing anything involving the runtime anymore. But any buildbot using a out-of-tree build of Flang or running the llvm-test-suite (which needs a runtime to run executables) is going to fail. For the lab.llvm.org CI, I am going to fix the builder configurations with an llvm-zorg patch. Any downstream CI infrastructure must be adapted separately:
For bootstraping configurations (llvm/CMakeLists.txt as top-level script and -DLLVM_ENABLE_PROJECTS=flang), just add -DLLVM_ENABLE_RUNTIMES=flang-rt and run check-flang-rt.
For for out-of-tree builds of only Flang’s runtime (flang/Runtime/CMakeLists.txt as top-level script), change the top-level script to runtimes/CMakeLists.txt and add -DLLVM_ENABLE_RUNTIMES=flang-rt -DLLVM_BINARY_DIR=<path-to-llvm-build-dir> -DCMAKE_Fortran_COMPILER_WORKS=ON and -DCMAKE_Fortran_COMPILER=<path-to-lllvm-build-dir>/bin/flang. Add -L<path-to-Flang-RT-build-dir>/lib to the CMAKE_*_FLAGS of the llvm-test-suite. Alternatively, use the same CMAKE_INSTALL_PREFIX for all builds and after installing refer to the compilers in the install’s bin directory.
For Flang out-of-tree builds (flang/CMakeLists.txt as top-level script), add the above as another build step, but use the out-of-tree Flang for CMAKE_Fortran_COMPILER.
Is there any reason that we can’t just add flang-rt to LLVM_ENABLE_RUNTIMES by default if flang is in LLVM_ENABLE_PROJECTS, so that there’s no change for end users here, like we do for mlir already? flang won’t actually work without the runtime so it seems that it’d be nice to add it automatically. I suppose there are some use cases that might want to build the runtimes separately and so don’t want flang-rt built when flang is but maybe we could add a DFLANG_ENABLE_FLANG_RT=Off flag to control this behaviour at that level?
I’m not fully opposed to having to add it to LLVM_ENABLE_RUNTIMES but it’d be nicer if -DLLVM_ENABLE_PROJECTS="flang" gave you a functional compiler on its own.
Some buildbot builders use out-of-tree builds of the runtime that should build the compiler without the runtime first, so changes to the buildbots are still required. Also, names of configuration variables are changing: They must be prefixed with FLANG_RT_ for the runtimes system to pass them through to the runtimes builds. I guess we could add compatibility code that detects that the runtime has already been built, and also set the new configuration variables if the old names have been defined by the user. Moreover, buildbot will not trigger on source changes in flang-rt if not providing depends_on_projects=['flang-rt'] (this is already the case for mlir)
Note that LLVM_ENABLE_PROJECTS=flang already does not work:
-- Enabling MLIR as a dependency to flang
CMake Error at CMakeLists.txt:149 (message):
Clang is not enabled, but is required for the Flang driver
For Clang, LLVM_ENABLE_PROJECTS=clang itself also does not yet provide a full toolchain. compiler-rt, libc, and for C++ libcxxabi, libcxx, libunwind are also requiried. It is just more typical that these components (or equivalents) are already available in the target environment.
Personally, I find implicitly changing user-provided CMake configuration parameters confusing. The need to even add a workaround to avoid stop doing so is a sympton, like the the potential problem with buildbots mentioned above.
Not saying we cannot do so, but seeing how the other runtimes work, providing LLVM_ENABLE_RUNTIMES=flang-rt is what I would expect if I want more than the compiler itself. Flang is already built differently than a typical CMake project. But what do others think?
I think the difference here between clang → compiler-rt and flang → flang-rt, at least as I see it, is that building just clang will still give you a functional compiler as it can rely on system libraries to do the things it needs compiler-rt for, and even then does not always need those things.
Conversely, flang will never be a functional compiler without flang-rt; it cannot rely on a system version of a Fortran runtime, and you can’t even compile the most basic of Fortran programs with flang without linking to the runtime.
I don’t feel particularly strongly about it though. It might be worth adding a warning or something to the CMake if you build flang without flang-rt? Then at least anyone who is doing it deliberately can ignore it, and anyone who isn’t will get told that they’re not going to end up with a functioning compiler.
This is the current message when building no Flang-RT in PR #110217:
The PR sequence retains the old CMake code for building the runtime, controlled by FLANG_INCLUDE_RUNTIME, which is by default is ON unless LLVM_ENABLE_RUNTIMES=flang-rt is used. What to do when removing the FLANG_INCLUDE_RUNTIME code can still be decided then.
The current build instructions for Flang already require more boilerplate than a typical CMake project. Specifically, LLVM_ENABLE_PROJECTS=flang alone already doesn’t work.