Helper macro for managing intermediate dependencies on Fortran modules.- Add SPEC2017 CPU ROMS floating point tests.
- Emit warning message about using recent Ninja version.
Details
Diff Detail
- Repository
- rT test-suite
Event Timeline
As far as I know, cmake detect module dependency itself, which would make speccpu2017_add_mod unnecessary.
I applied the patch locally and change the compilation part to just speccpu2017_add_executable() and it still compiles.
External/SPEC/CFP2017rate/554.roms_r/CMakeLists.txt | ||
---|---|---|
49 | Leftover fotonik3d | |
370 | Consider using target_link_libraries (https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries) for linking object libraries. The tutorial uses generator expressions ($<TARGET_OBJECTS:${PROG}_Fortran_MOD_4>) which are missing here? | |
External/SPEC/SpecCPU2017.cmake | ||
342 ↗ | (On Diff #323880) | [typo] heirarchy |
It is not really clear from the CMake docs that it can figure out complex module dependencies without intermediary targets. Searching online, it looks like many Fortran-centric projects have come up with different solutions.
If the name of the macro is the issue, we can change it to something else besides speccpu2017_add_mod
I applied the patch locally and change the compilation part to just speccpu2017_add_executable() and it still compiles.
Does it work for you if you at make -j 10 or the equivalent with ninja? It is definitely failing to build for me when I increase the number of parallel builds due to missing .mod files.
External/SPEC/CFP2017rate/554.roms_r/CMakeLists.txt | ||
---|---|---|
370 |
The downside is that we would have to bump the minimum CMake requirement to 3.12 and right now the minimum requirement is 3.4.3. I am concerned that it could break any buildbots out there using older CMake versions.
I think you are right. I should also change it for the other add_dependencies(..) statements. |
LLVM required cmake 3.13.4, I think we can bump the version for llvm-test-suite as well.
- Run ROMS test out of run directory.
- Revert "Helper macro for managing intermediate dependencies on Fortran modules."
- Add warning about CMAKE_GENERATORS that are not Ninja.
- Fix comment to reflect ROMS test.
- Intermediate target dependencies are not needed when using Ninja.
Btw, I found the following at https://blog.kitware.com/fortran-for-cc-developers-made-easier-with-cmake/ (from 2012):
Building Fortran in the correct order
Fortran 90 supports a module system that allows Fortran to import and export modules from source files. This adds a huge complexity to the build problem as the Fortran code must be compiled in the correct order to ensure that module files are available for import after they have been exported, but before they are imported. To accomplish this, CMake contains a full Fortran parser. When CMake computes depend information at build time, it will parse all of the Fortran sources. The parser determines which files are producers and which files are the consumers, and then it uses that information to order the build. There is no user interaction with CMake in order to use this feature. It is only used with Makefile builds. The Intel VS Fortran IDE plugin handles this itself.
CMakeLists.txt | ||
---|---|---|
11 | Some generators have spaces in their name ("UNIX Makefiles"), I recommend using quotes. The syntax of STREQUAL is <variable|string> STREQUAL <variable|string>, so if(NOT CMAKE_GENERATOR STREQUAL "Ninja") should work too. | |
13–14 | When I tried the "UNIX Makefile" generator, it did not even build sequentially. Could you add that to the message that this is a warning about the Generator/-G switch? A user who does not know about what ninja is might be confused by this message. |
Some generators have spaces in their name ("UNIX Makefiles"), I recommend using quotes.
The syntax of STREQUAL is <variable|string> STREQUAL <variable|string>, so
should work too.