It looks like rclcpp_components_register_nodes()calls _rclcpp_components_register_package_hook This is a macro that calls ament_register_extension(). This is probably because in CMake each call to add_subdirectory() creates a new scope, meaning CMake variables set in the subdirectory are not visible to the parent directory. For some projects like stdlib or DFTB+ which use fypp, a reconfigure step might result in rerunning the preprocessor, therefore changing all the files and triggering a complete rebuild, which can become expensive in rebuild times for adding one file.If I take the contents of the subdirectories' CMakeLists.txt file to the main CMakeLists.txt and remove the call to add_subdirectory, everything works fine. Also, with clear separation of the tasks performed in different CMakeLists.txt files it is always easy to check if a change in a file just adds/removes source files or changes the build logic and therefore requires extra attention.Įdit: seems like a change in the GLOB result will trigger the reconfiguration automatically since CMake 3.12, this should remove this minor annoyance. This is especially annoying if you just started the project and add new source files as you write new modules and always have to remember that you must touch some CMakeLists.txt to trigger a reconfiguration or your build will not work correctly.įind a style you like and you can work with, I personally adopted the above style because it produces smaller diffs in the build files and makes the intention of certain values clearer. I recommend to avoid GLOB because it is expanded at configure time rather than at build time, adding new source files requires to trigger a reconfiguration to have CMake recognized there are new files in the tree that should be included.
source3/CMakeLists.txtĪs usual with CMake there is more than one way to write build files that just work. While you have the main.f90 file in this directory, I would find it surprising to have the main program compiled here, but its modules stored in the top-level instead, therefore I’m just collecting main.f90 like every other source and handle the compilation in the top-level. Finally, you have to pass the appended source files up again to the PARENT_SCOPE. My personal preference is to define targets, at least libraries, in the top-level, it makes it easier to inspect the top-level CMakeLists.txt and know what the build actually does, while most of the subdirectories only collect sources and pass them back up to the top-level.įor each subdirectory I’m usually defining the current directory as local variable because I don’t want to type CMAKE_CURRENT_SOURCE_DIR every time. Set(CMAKE_Fortran_MODULE_DIRECTORY $/mod" My top-level CMakeLists.txt is: # my_cool_project/CMakeLists.txt
I am struggling to write a CMakeLists.txt that automagically figures out the dependency graph and builds the main program. There are dependencies between the directories, such that each one cannot be built independently. Some of these source files define modules, while others are naked subroutines.
The main program is written in main.f90, which calls subroutines defined in the other source files. I’ve got a project that has the following directory structure my_cool_project/
0 kommentar(er)
