Closed samuelpmishLLNL closed 11 months ago
Here is one potential CMake project implementation for a library (e.g. axom) that optionally builds some combination of components based on user-specified options: library_of_components.zip
Making changes to the CMake project and reconfiguring doesn't result in a complete rebuild. If a user previously built this library and then decides to turn on one of the optional components, only that new component library is compiled (object files from the other components are reused, rather than recompiled). Making other changes to the CMake project that don't affect the component builds requires no recompilation.
It is my understanding that there are two parts to this issue and I will address them separately.
1) Turning off individual components
Axom has CMake options to allow turning off individual components. The options are documented here:
We cannot turn off components in Serac due to what Serac requires but more to the point Tribol requires all of Axom. I did create two PRs that limit the inheritance of the targets so, while they are all built, it does limit the need to link them up the chain.
2) Touching CMake files causes rebuilding of part of Axom
This is more tricky. I was able to confirm that in Serac's Codevelop build that part (not all) of Axom is rebuilt when you only touch a CMake file. This does not happen in straight Axom though.
I have looked over all the things we do to make the Codevelop build work and nothing stands out in touching or reconfiguring files which is usually the case.
If you can figure out why Serac's codevelop build triggers a partial rebuild, I would be glad for a fix.
But for now this should be closed because its not an Axom issue.
I have looked over all the things we do to make the Codevelop build work and nothing stands out in touching or reconfiguring files which is usually the case.
If you can figure out why Serac's codevelop build triggers a partial rebuild, I would be glad for a fix.
ninja
will tell you why it's recompiling individual files:
serac/build % ninja -d explain
...
ninja explain: axom/axom/mint/CMakeFiles/mint.dir/fem/FiniteElement.cpp.o is dirty
ninja explain: output axom/axom/mint/CMakeFiles/mint.dir/mesh/internal/MeshHelpers.cpp.o older than most recent input /home/sam/code/serac/build/mfem/mfem.hpp (1699386084663511236 vs 1699386110103460827)ninja explain: axom/axom/mint/CMakeFiles/mint.dir/mesh/internal/MeshHelpers.cpp.o is dirty
ninja explain: output axom/axom/mint/CMakeFiles/mint.dir/mesh/CurvilinearMesh.cpp.o older than most recent input /home/sam/code/serac/build/mfem/mfem.hpp (1699386084475511608 vs 1699386110103460827)
...
It seems mfem is just regenerating mfem.hpp
every time and many of axom's sourcefiles include it, so they end up getting recompiled as a result. A simple fix (in mfem) would be to only emplace the generated mfem.hpp
file into the build directory if its contents are different than what's there already.
In serac, whenever I touch any of our cmake files, axom (0da8a5b1b, built alongside serac with
add_subdirectory
) also gets reconfigured since it's one of our dependencies. Even if the change to the cmake file is unrelated to axom, it still triggers a complete rebuild of all of our axom components:Other targets built as part of this CMake project are unaffected (mfem, serac subcomponents, etc)-- it's only the axom targets that recompile.
I'm looking for a way to avoid paying this cost each time I interact with our build system. Additionally, when setting some of the optional components to OFF (we don't even use slam, quest, primal, klee, mint), linking against the
axom
target seems to still bring them them in on the link line, leading to compilation errors. The linkage error may be specific to serac, that part is still unclear to me.Is it possible to prevent axom from recompiling everything when making a change to a CMake file?