FTL in CMake project - error using GNU Make

[jeffhole]

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:

  1 program hello
  2     use ftlStringModule
  3     use ftlHashMapStringIntModule
  4     implicit none
  5 
  6     type(ftlHashMapStringInt) :: dist
  7     integer :: d1
  8     type(ftlString) :: city, dstr
  9 
 10     ! Create map.
 11     call dist%New(10)
 12     ! Add some values to the map.
 13     call dist%Set('London', 1020)
 14     call dist%Set('New York', 6380)
 15     call dist%Set('Paris', 850)
 16     call dist%Set('Tokyo', 8900)
 17 
 18     ! Find some values in the map.
 19     d1 = dist%Get('Paris')
 20     call  dstr%New(d1)
 21     print *, 'Paris is ', dstr, 'km away.'
 22 
 23     city = 'Beijing'
 24     if (.not. dist%Has(city)) then
 25         print *, "I don't know distance to Beijing."
 26     else
 27         print *, 'How can that be?'
 28     end if
 29 end program

ftlHashMapString.f90:

  1 ! Defines string-integer map: ftlHashMapStringInt
  2 #define FTL_TEMPLATE_KEYTYPE_IS_FTLSTRING
  3 #define FTL_TEMPLATE_KEYTYPE_NAME String
  4 #define FTL_TEMPLATE_TYPE integer
  5 #define FTL_TEMPLATE_TYPE_NAME Int
  6 #define FTL_INSTANTIATE_TEMPLATE
  7 #include <ftlHashMap.F90_template>

Makefile:

  1 FC=gfortran
  2 FOPTS=-cpp -I usr/include/ftl -Lusr/lib/ -lftl
  3 
  4 main : main.f90 ftlHashMapStringInt.o
  5     $(FC) $(FOPTS) main.f90 ftlHashMapStringInt.o -o main 
  6 
  7 ftlHashMapStringInt.o : 
  8     $(FC) $(FOPTS) -c ftlHashMapStringInt.f90

Here's the output of the program main (as expected):

 Paris is  850 km away.
 I don't know distance to Beijing.

CMake - Make Build System

CMakeLists.txt:

  1 cmake_minimum_required(VERSION 3.20)
  2 
  3 project(test-ftl LANGUAGES Fortran)
  4 set(CMAKE_Fortran_PREPROCESS YES)
  5 
  6 add_executable(main main.f90 ftlHashMapStringInt.f90)
  7 target_include_directories(main PUBLIC usr/include/ftl/)
  8 target_link_directories(main PUBLIC usr/lib/)
  9 target_link_libraries(main PUBLIC ftl)

Generate the build system and call make:

cmake -B build
cd build
make

Output of make:

Scanning dependencies of target main
[ 33%] Building Fortran object CMakeFiles/main.dir/ftlHashMapStringInt.f90.o
Error copying Fortran module "cat4.mod".  Tried "CAT4.mod" and "cat4.mod".
make[2]: *** [CMakeFiles/main.dir/depend.make:12: CMakeFiles/main.dir/cat4.mod.stamp] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/main.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

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:

cmake -B build -G Ninja
cd build
ninja

Ninja output:

[6/6] Linking Fortran executable main

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

• The ninja available from dnf install ninja-build, is an older version 1.8.2, which did not play nice with CMake 3.20.2.

[jeffhole]

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.