Export informational variables to <Package>Config.cmake files for downstream CMake projects

[bartlettroscoe]

Parent Issue

• EPIC: Initial TriBITS Modernization and Generalization #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 Address failures from merge of updated TriBITS (#10614, TriBITSPub/TriBITS#299) trilinos/Trilinos#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:

tribits_pkg_export_cache_var(<cacheVarName>)

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 in tribits_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 call tribits_pkg_export_cache_var(<userOptionName>) and tribits_pkg_export_cache_var(<macroDefineName>) (when those functions are called with a package scope). Other examples of standard TriBITS option-setting functions that would call tribits_pkg_export_cache_var() are tribits_add_debug_option(), ???.

And to avoid duplication, we could provide TriBITS functions tribits_pkg_set_option_and_export(<optionName> <defaultVal>) and tribits_pkg_set_and_export(<varName> <defaultVal> CACHE <type> "<doc>") and packages could refactor that currently calls option(<optionName> <defaultVal>) and set(<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 in TribitsExampleApp2:

TriBITS/tribits/examples/TribitsExampleApp2/AppHelperFuncs.cmake

Lines 144 to 162 in 4c184b4

	if (Package2_ENABLE_Tpl3)
	set(package2_tpl3_deps_str ", ${tpl3}")
	else()
	set(package2_tpl3_deps_str "")
	endif()
	set(package2 "Package2{${package1}${package2_tpl3_deps_str}}")
	if (Package3_ENABLE_Package2)
	set(package3_package2_deps_str "${package2}, ")
	else()
	set(package3_package2_deps_str "")
	endif()
	if (Package3_ENABLE_Tpl4)
	set(package3_tpl4_deps_str "${tpl4}, ")
	else()
	set(package3_tpl4_deps_str "")
	endif()
	set(package3
	"Package3{${package3_package2_deps_str}${package1}, ${package3_tpl4_deps_str}${tpl2a}, ${tpl2b}}")

[bartlettroscoe]

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.

[bartlettroscoe]

Irina Tezaur confirmed that this works for the Anasazi_ENABLE_RBGen case described above.

Closing as complete.