Move to modern CMake target-based propagation of build information #299
Comments
|
This refactoring will make it easier to integrate Kokkos and KokkosKernels into Trilinos as described in the below email from @jjwilke. From: Wilke, Jeremiah J [email protected] Below would be my (very specific) action items to get where we need to be. • Move to CMake 3.13 (allows link_options and better with flag deduplication) I would guess this could be done in a month? Once this is done, it should be straightforward to design a system where Kokkos could be a TPL. -Jeremy |
|
The Trilinos issue to allow the upgrade of the minimum version of CMake from 3.10 to 3.13 for TriBITS as well is trilinos/Trilinos#6752. |
|
This brings up another issue. These refactorings of TriBITS to use target-centric features in CMake may make it very difficult to maintain backward comparability with-respect to the build system. For example, it may not be possible keep supporting the generation of |
|
I think we can probably make this work? Everything that needs to be in the Makefile will end up in That doesn't rely on variables like |
|
This will also be relevant to #127 (comment). |
|
FWIW, SCALE/Exnihilo is only using the exported tribits config.cmake files for the downstream enrico project, not any makefile.export. I'm definitely OK with a transition plan for removing backward compatibility gradually 😬 |
|
I will say (and maybe @bradking already knows how to do this) - the reason I stopped short of exporting a Makefile.kokkos was generator expressions in the property lists. |
Modern CMake target-based usage requirements mean that much of the logic to convert project CMake code into the final build system command-lines is handled by CMake's generators. The input to that process is not exportable to |
It occurred to me that it still might be possible to produce |
|
FYI: I just got feedback from lead INL MOOSE framework lead that they dropped testing against Trilinos (because CASL has ended) and don't plan on supporting Trilinos going forward (unless something changes). Therefore, because I think we could add support for |
|
FYI: It just occurred to me that the SNL Sierra project might be using Makefile.export.Trilinos for its custom bJam/bake build system that uses the native Trilinos TriBITS/CMake build system. I have reached out to them to see if that is the case. |
|
FYI: Got back a response from the SNL Sierra DevOps lead that Sierra actually does not use the Makefile.export.Trilinos file. They actually manually maintain a set of BJam files for building Trilinos and they get the info they need from that (even when building Trilinos using the native TriBITS CMake build system). Therefore, it looks like we don't need to keep generating Makefile.export.Trilinos files based on SNL Sierra needs. That is good news :-) |
|
Someone just showed me the option CMAKE_EXPORT_COMPILE_COMMANDS which writes a |
|
FYI: I just realized that PETSc is still using the So I think unless PETSc switches over to CMake, we are going to need to re-implement support for at least the |
|
Or just require PETSc to use older trilinos/tribits version until they switch? |
Not sure that is a viable option because of the ECP xSDK and E4S that includes PETSc and Trilinos. But to get by, someone can just manually generate a And I have no idea what the timetable would be for PETSc to switch to CMake (or even if that is a firm plan). CC: @keitat |
|
FYI: Looks like the refactored TriBITS may need to need to keep defining the vars I wonder how much code like this exists in Trilinos and other projects using Trilinos? |
When find_package(<externalPkg>) uses a find module Find<exteranlPkg>.cmake instead of a package config file <externalPkg>Config.cmake, the variable. <externalPkg>_DIR is not set. Therefore, it is best to not set <externalPkg>_DIR in the TriBITS-geneated <tplName>Config.cmake file since that is just confusing. NOTE: This is only a situation that comes up when a TriBITS FindTPL<tplName>.cmake module calls find_package(<externalPkg>).
When find_package(<externalPkg>) uses a find module Find<exteranlPkg>.cmake instead of a package config file <externalPkg>Config.cmake, the variable. <externalPkg>_DIR is not set. Therefore, it is best to not set <externalPkg>_DIR in the TriBITS-geneated <tplName>Config.cmake file since that is just confusing. NOTE: The case where TriBITS a FindTPL<tplName>.cmake module calls find_package(<externalPkg>) is the only a situation where this is the case. When one TriBITS TPL is calling find_dependency() on an upstream TriBITS TPL, the <upstreamDepTpl>_DIR variable is always set.
…BITSPub#299, TriBITSPub#63) This commit gets rid of several list variables that are not needed with the move to modern CMake and some fairly complex code that was needed to compute these list variables: * <Project>_REVERSE_DEFINED_INTERNAL_PACKAGES * <Project>_REVERSE_DEFINED_TPLS * <Project>_TPL_LIST * <Package>_PACKAGE_LIST * <Package>_TPL_LIBRARIES * <Package>_TPL_LIST * <Package>_LIBRARY_DIRS * <Package>_INCLUDE_DIR * <Package>_TPL_LIBRARIES * <Package>_TPL_LIBRARY_DIRS * <Package>_TPL_INCLUDE_DIR
…#299, TriBITSPub#63) Unfortunately, I could not remove the computation of the full set of direct and indirect dependencies for each pacakge <Package>_FULL_ENABLED_DEP_PACKAGES because the function tribits_find_most_recent_file_timestamp() still needs this. The only customer that still needs that function is CASL VERA (to compute when it is needed to rebuild MOOSE). Therefore, for now, I can't remove this code (which is more complex and can be an expensive computation if there are a **lot** of packages).
…BITSPub#299, TriBITSPub#63) This commit gets rid of several list variables that are not needed with the move to modern CMake and some fairly complex code that was needed to compute these list variables: * <Project>_REVERSE_DEFINED_INTERNAL_PACKAGES * <Project>_REVERSE_DEFINED_TPLS * <Project>_TPL_LIST * <Package>_PACKAGE_LIST * <Package>_TPL_LIST * <Package>_INCLUDE_DIR * <Package>_LIBRARY_DIRS * <Package>_TPL_INCLUDE_DIRS * <Package>_TPL_LIBRARIES * <Package>_TPL_LIBRARY_DIRS
…#299, TriBITSPub#63) Unfortunately, I could not remove the computation of the full set of direct and indirect dependencies for each pacakge <Package>_FULL_ENABLED_DEP_PACKAGES because the function tribits_find_most_recent_file_timestamp() still needs this. The only customer that still needs that function is CASL VERA (to compute when it is needed to rebuild MOOSE). Therefore, for now, I can't remove this code (which is more complex and can be an expensive computation if there are a **lot** of packages).
…#299, TriBITSPub#63) Unfortunately, I could not remove the computation of the full set of direct and indirect dependencies for each pacakge <Package>_FULL_ENABLED_DEP_PACKAGES because the function tribits_find_most_recent_file_timestamp() still needs this. The only customer that still needs that function is CASL VERA (to compute when it is needed to rebuild MOOSE). Therefore, for now, I can't remove this code (which is more complex and can be an expensive computation if there are a **lot** of packages).
…BITSPub#299, TriBITSPub#63) This commit gets rid of several list variables that are not needed with the move to modern CMake and some fairly complex code that was needed to compute these list variables: * <Project>_REVERSE_DEFINED_INTERNAL_PACKAGES * <Project>_REVERSE_DEFINED_TPLS * <Project>_TPL_LIST * <Package>_PACKAGE_LIST * <Package>_TPL_LIST * <Package>_INCLUDE_DIR * <Package>_LIBRARY_DIRS * <Package>_TPL_INCLUDE_DIRS * <Package>_TPL_LIBRARIES * <Package>_TPL_LIBRARY_DIRS
…#299, TriBITSPub#63) Unfortunately, I could not remove the computation of the full set of direct and indirect dependencies for each pacakge <Package>_FULL_ENABLED_DEP_PACKAGES because the function tribits_find_most_recent_file_timestamp() still needs this. The only customer that still needs that function is CASL VERA (to compute when it is needed to rebuild MOOSE). Therefore, for now, I can't remove this code (which is more complex and can be an expensive computation if there are a **lot** of packages).
…BITSPub#299, TriBITSPub#63) This commit gets rid of several list variables that are not needed with the move to modern CMake and some fairly complex code that was needed to compute these list variables: * <Project>_REVERSE_DEFINED_INTERNAL_PACKAGES * <Project>_REVERSE_DEFINED_TPLS * <Project>_TPL_LIST * <Package>_PACKAGE_LIST * <Package>_TPL_LIST * <Package>_INCLUDE_DIR * <Package>_LIBRARY_DIRS * <Package>_TPL_INCLUDE_DIRS * <Package>_TPL_LIBRARIES * <Package>_TPL_LIBRARY_DIRS Some of these changes impact only internal code but some impact even customers of the installed <Project>Config.cmake and <Package>Config.cmake files (see the new entries in tribits/CHANGELOG.md). This required some minor updates to the example projects: * tribits/examples/TribitsExampleApp/ * tribits/examples/TribitsOldSimpleExampleApp/ * tribits/examples/TribitsSimpleExampleApp/ for some logic that used <Project>_TPL_LIST. (There is no need to use that with updated TriBITS. See the diffs in this commit for those projects to see how they were adjusted.)
…SPub#299) I noticed some of these issue while reading the documentation online.
…SPub#299) I noticed some of these issue while reading the documentation online.
…riBITSPub#299) This is to avoid clashes such as reported in: * TriBITSPub#548 like CUDA::cufft from FindCUDAToolkit.cmake and fmt::fmt from Findfmd.cmake.
…rilinos#11545) With the TriBITS modernization refactoring (TriBITSPub/TriBITS#299) and the generalizated handling of intenral and external packages (TriBITSPub/TriBITS#63), we need packages like Kokkos to set critical compiler options as target properties so that they will be exported in the generated IMPORTED targets of the Kokkos<Subpkg>Targets.cmake file. This is needed, for example, to pass some critical compiler flags from the pre-installed Kokkos to downstream CMake configures of KokkosKernels and the rest of Trilinos (see trilinos#11545).
…rilinos#11545) With the TriBITS modernization refactoring (TriBITSPub/TriBITS#299) and the generalizated handling of intenral and external packages (TriBITSPub/TriBITS#63), we need packages like Kokkos to set critical compiler options as target properties so that they will be exported in the generated IMPORTED targets of the Kokkos<Subpkg>Targets.cmake file. This is needed, for example, to pass some critical compiler flags from the pre-installed Kokkos to downstream CMake configures of KokkosKernels and the rest of Trilinos (see trilinos#11545).
…BITSPub/TriBITS#299) Support for Makefile.export.* files was removed from TriBITS and snaphsotted into Trilinos a long time ago. This support was removed in the Trilinos 14.0 release. There is no reason to keep this cache variable anymore. It just clutters up the base CMakeLists.txt file.
…BITSPub/TriBITS#299) Support for Makefile.export.* files was removed from TriBITS and snaphsotted into Trilinos a long time ago. This support was removed in the Trilinos 14.0 release. There is no reason to keep this cache variable anymore. It just clutters up the base CMakeLists.txt file.
…BITSPub/TriBITS#299) Support for Makefile.export.* files was removed from TriBITS and snaphsotted into Trilinos a long time ago. This support was removed in the Trilinos 14.0 release. There is no reason to keep this cache variable anymore. It just clutters up the base CMakeLists.txt file.
Parent Issue:
Child Issues:
Blocked By: trilinos/Trilinos#8498
Description
One of the things holding back TriBITS and projects using TriBITS in accessing new features of CMake for which TriBITS still using variables to manage compiler options and include directories. This issue is to move to using:
and to move completely to targets instead of variables for each TriBITS (internal and external) package.
This needs to be done as part of a comprehensive refactoring as part of #63.
This refactoring should implement and respect this proposed standard for
<Package>Config.cmakefiles.Related to:
Tasks
PUBLICtotarget_link_libraries()in TriBITS intra-package linking${PACKAGE_NAME}::<lib-name>targets and${PACKAGE_NAME}::all_libsINTERFACE library targets for TriBITS packages andtarget_link_libraries( ... PUBLIC ... )to define dependencies to upstream packages. (see PR Convert TriBITS over to use self-contained modern CMake targets for internal packages (#299) #424)${TPL_NAME}::all_libsINTERFACE GLOBAL library targets for TPLs and usetarget_link_libraries( ... INTERFACE ... )to define dependencies between TPLs.target_include_directories()<Package>_INCLUDE_DIRS,<Package>_TPL_INCLUDE_DIRS,<Package>_LIBRARIESor<Package>_LIBRARY_DIRS).<Package>_INCLUDE_DIRS,<Package>_TPL_INCLUDE_DIRS,<Package>_LIBRARIESand<Package>_LIBRARY_DIRS.The text was updated successfully, but these errors were encountered: