Open jeffhole opened 10 months ago
I recreated the issue with a simple example and opened an issue at CMake (issue 25380). I did find a 6-year old issue (issue 16853) on the CMake repo that seems to indicate that the CMake doesn't do full preprocessing when generating the Make build system. The responder suggests using the Ninja build system:
CMake's Fortran dependency scanner for the Makefile generators does not do full preprocessing so cases like this cannot be handled. It's not something that we can really fix without major new infrastructure. You could try using the Ninja generator instead. It handles dependencies with a full separate preprocessing step.
EDIT: This is an issue with CMake, not with the FTL, and it doesn't appear to be something that can be worked around easily. See my second comment for more information regarding CMake where I reached out to the devs, and got word confirming this as a shortcoming of the current CMake Make generator.
I jumped right in testing out the FTL containers with a String/Integer Hash Map example with a simple makefile. First, I installed a copy of the FTL compiled from source (using the instruction in above link) into the same directory as the example code (under current_dir/usr/), and was sure to set my LD_LIBRARY_PATH to find libftl.so. It worked!
I then tried getting the same example working using CMake to generate the build system. I ran into an error when generating a Make build system (GNU Make 4.2.1 in GCC toolchain 10.3.1), but there wasn't an issue when using the latest Ninja build system (version 1.11.1).
All files mentioned below (main.f90, ftlHashMapStringInt.f90, Makefile, CMakeLists.txt) are in the "current" directory.
Custom Makefile Version (working)
main.f90:
ftlHashMapString.f90:
Makefile:
Here's the output of the program
main
(as expected):CMake - Make Build System
CMakeLists.txt:
Generate the build system and call make:
Output of make:
Without digging in any further, it appears when cmake analyzes module dependencies, it sees the preprocessor macro
CAT4
which appears right after "module" in ftlHashMap.F90_template, and generates a target/rule for the.mod
file.I don't think this is a bug in FTL, but more of a deficiency in cmake preprocessing the files as it builds a dependency graph of the project for Make. To check this, I decided to try a different build system and picked Ninja.
Generate the build system and call ninja:
Ninja output:
No problems. And the program runs and produces the expected output (shown above). My takeaway is that there is an issue with CMake's Make build system because Ninja worked exactly as expected.
Bottom line, I think it'd be worth finding a solution to this problem so that FTL users can incorporate it into their CMake projects where GNU Make is the build system of choice.
Why Bother Telling You This?
I am a big fan of Fortran and its community of developers. I want these tools to succeed. Therefore, when there is something that might hinder someone adopting the tools, I want to help be a part of the solution. Since the default build system in CMake is Make, I figure that it'd be worth the effort to get FTL working with it.
Versions of tools I'm using
I am using the GCC toolchain version 10.3.1 (GNU Make 4.2.1) on Rocky Linux 8.8 CMake version 3.20.2 Ninja (v.1.11.1) downloaded the Linux binary and put in my PATH
dnf install ninja-build
, is an older version 1.8.2, which did not play nice with CMake 3.20.2.