[Flang][runtime] Add dependency to build FortranRuntime after flang-new

[mjklemm]

Makefile-based builds did not have proper dependencies to built the FortranRuntime target after Flang new is available. This PR introduces a dependency to ensure that this is the case. Relates to PR #95388.

[llvmbot]

@llvm/pr-subscribers-flang-runtime

Author: Michael Klemm (mjklemm)

Changes

Makefile-based builds did not have proper dependencies to built the FortranRuntime target after Flang new is available. This PR introduces a dependency to ensure that this is the case. Relates to PR #95388.

---

Full diff: https://github.com/llvm/llvm-project/pull/99737.diff

1 Files Affected:

• (modified) flang/runtime/CMakeLists.txt (+6)

diff --git a/flang/runtime/CMakeLists.txt b/flang/runtime/CMakeLists.txt
index 8588af7e16eec..6d435f00b8965 100644
--- a/flang/runtime/CMakeLists.txt
+++ b/flang/runtime/CMakeLists.txt
@@ -295,3 +295,9 @@ else()
     FortranRuntime.static_dbg FortranRuntime.dynamic_dbg)
 endif()
 set_target_properties(FortranRuntime PROPERTIES FOLDER "Flang/Runtime Libraries")
+
+# Add dependency to make sure that Fortran runtime library is being built after
+# we have the Flang compiler available.  This also includes the MODULE files
+# that compile when the 'flang-new' target is built.
+add_dependencies(FortranRuntime flang-new)
+

[vzakhari]

Thank you, Michael.
Please note that FortranRuntime is expected to be buildable as a standalone project (see at the top of this file) - this is not going to work, and you will probably see some buildbots failures soon (e.g. https://lab.llvm.org/buildbot/#/builders/152).
It seems the module file has to be made a part of FortranRuntime as @sscalpone suggested in the original PR.

[vzakhari]

It seems just module_files should be enough.

[mjklemm]

Yeah, then we will have to rely on transitive dependencies FortranRuntime->module_files->flang-new. I'd like to be more explicit here to make sure that it's easier to understand.

[mjklemm]

If we revert the ISO_FORTRAN_ENV PR, then we will have to accept that several applications will break.

Reworking the runtime build system to be a "real runtime library build", seems to be too extensive for 19.x and I had suggested to start this work for the 20.x development cycle.

[mjklemm]

I'd appreciate hints on how to remove this dependency (for now) to re-enable runtime builds, albeit then w/o having the symbols coming from iso_fortran_env_impl.o.

[mjklemm]

@vzakhari

Please note that FortranRuntime is expected to be buildable as a standalone project (see at the top of this file) - this is not going to work

Do you have the ability to do a quick build with FortranRuntime as a standalone build with PR patched in? I think it should work, but I do not have a such a build set up to test myself.

[vzakhari]

Hi Michael, I think it should "work" for the standalone build, except that the library will not have the module linked in. This is an acceptable workaround for the device build of FortranRuntime, as long as we cannot build the new module for the device anyway. I will be able to check your patch on Monday PST, but I think you can merge it right away to fix the dependency issue for the in-tree builds.

BTW, my guess about failing the flang-runtime-cuda-gcc build was wrong. I think it did not fail just because FORTRAN_MODULE_OBJECTS variable is empty in the standalone build.

[Meinersbur]

LGTM

[Meinersbur]

@vzakhari I interpreted standalone as FLANG_STANDALONE_BUILD=ON", but now I think you mean using the flang/runtime/CMakeLists.txt as top-level files. That indeed yields an incomplete libFortranRuntime.a because FORTRAN_MODULE_OBJECTS is undefined. To get a complete one, one would just ask CMake to find a Fortran compiler (project(FlangRuntime C CXX Fortran)) and add iso_fortran_env_impl.f90 to source so CMake is responsible to compile it (preferably using -DCMAKE_Fortran_COMPILER=flang-new).

This patch doesn't change anything and since it checks the existence of the targets beforehand so will not introduce new failures.