Closed bartlettroscoe closed 2 years ago
With the merge of PRs #520 and #521, I think enough of this scope is done. I will defer the implementation of the macros tribits_pkg_set_option_and_export(<optionName> <defaultVal>)
and tribits_pkg_set_and_export(<varName> <defaultVal> CACHE <type> "<doc>")
until later, if they are needed.
I will put in review for now.
Irina Tezaur confirmed that this works for the Anasazi_ENABLE_RBGen case described above.
Closing as complete.
Parent Issue
367
Description
It is often the case that downstream CMake projects need to know how an upstream CMake project was configured and what features it supports. For example:
Albany wants to know if the installed Anasazi package was configured with RBGen or not (i.e. the value of
Anasazi_ENABLE_RBGen
). (needed to resolve an issue for https://github.com/trilinos/Trilinos/issues/10774).Once Trilinos packages are made to be built and installed independently, then downstream Trilinos packages will need to know a lot about upstream Trilinos packages. For example, downstream packages like MueLu need to know a lot about how upstream package Tpetra was configured (e.g. what scalar types it supports and has explicit template instantiations for).
Proposed solution
The proposed solution is to provide an easy mechanism for a TriBITS packages to make sure that the values of select cache vars are set in the generated
<Package>Config.cmake
file. For example, TriBITS could provide the function:such that when called, the variable
<cacheVarName>
and its value would get written into the<Package>Config.cmake
files for the package and its subpackages (if the package has subpackages). There would be code intribits_pkg_export_cache_var()
that asserted that the cache variable<cacheVarName>
existing and it was indeed a cache var (so that internal downstream packages can already see the value).Then many of the standard TriBITS variables like
tribits_add_option_and_define(<userOptionName> <macroDefineName> ...)
would calltribits_pkg_export_cache_var(<userOptionName>)
andtribits_pkg_export_cache_var(<macroDefineName>)
(when those functions are called with a package scope). Other examples of standard TriBITS option-setting functions that would calltribits_pkg_export_cache_var()
aretribits_add_debug_option()
, ???.And to avoid duplication, we could provide TriBITS functions
tribits_pkg_set_option_and_export(<optionName> <defaultVal>)
andtribits_pkg_set_and_export(<varName> <defaultVal> CACHE <type> "<doc>")
and packages could refactor that currently callsoption(<optionName> <defaultVal>)
andset(<varName> <defaultVal> CACHE <type> "<doc>")
, respectively.NOTE: The precedent of exporting
<Package>_ENABLE_<something>
variables into<Package>Config.cmake
files has already been done for the direct upstream dependencies of a TriBITS package to tell downstream CMake projects what upstream dependencies are enabled for a given packages. An example of this is inTribitsExampleApp2
:https://github.com/TriBITSPub/TriBITS/blob/4c184b45cdf73b14da2c026e97203238c65f87f4/tribits/examples/TribitsExampleApp2/AppHelperFuncs.cmake#L144-L162