bartlettroscoe
commented
1 year ago CC: @jwillenbring, @KyleFromKitware
Following up on the task above:
- Figure out how should we treat TPLs that are enabled in the pre-installed packages in the downstream TriBITS project? (We should not be finding them again but should just use them as found by the upstream TriBITS-compatible package installed.)
This is more complex than it would first seem. For example, with TribitsExampleProject, when we enable SimpleTpl and configure, build and install SimpleCxx, we should not be trying to find HeaderOnlyTpl and SimpleTpl again when we configure the rest of TribitsExampleProject when we pull in SimpleCxx as a pre-installed external package/TPL, we should not be trying to find HeaderOnlyTpl or SimpleTpl again (i.e. like we currently are as shown here in TEST_7 Configure rest of TribitsExampleProject against pre-installed SimpleCxx). Likewise, when we build and install Kokkos and then build the rest of Trilinos against Kokkos, we should not be trying to find the TPLs that Kokkos depends on either. The TriBITS TPLs being used by Kokkos are Pthread, CUDA, HWLOC, CUSPARSE and DLib as shown by:
$ cd Trilinos/
$ find packages/kokkos -name Dependencies.cmake -exec echo \; -exec echo {} \; -exec echo \; -exec grep _TPLS {} \;
packages/kokkos/algorithms/cmake/Dependencies.cmake
LIB_OPTIONAL_TPLS Pthread CUDA HWLOC
TEST_OPTIONAL_TPLS CUSPARSE
packages/kokkos/cmake/Dependencies.cmake
packages/kokkos/containers/cmake/Dependencies.cmake
LIB_OPTIONAL_TPLS Pthread CUDA HWLOC
TEST_OPTIONAL_TPLS CUSPARSE
packages/kokkos/core/cmake/Dependencies.cmake
LIB_OPTIONAL_TPLS Pthread CUDA HWLOC DLlib
TEST_OPTIONAL_TPLS CUSPARSE
packages/kokkos/simd/cmake/Dependencies.cmake
LIB_OPTIONAL_TPLS Pthread CUDA HWLOC
TEST_OPTIONAL_TPLS CUSPARSEWe should not be trying finding these TPL again when we pull in pre-installed Kokkos when building downstream packages but should instead use what was found in the the upstream Kokkos package configure.
Likewise, what about a case with Trilinos where you might be installing Tpetra and all of its upstream internal package (e.g. Epetra, Teuchos, KokkosKernels, Kokkos) and external packages (e.g. CUDA, CUBLAS, CUSOLVER, BLAS, LAPACK, Pthread, etc.). So in that case, none of the these upstream external packages/TPLs should be directly processed but should instead just process the external package/TPL Tpetra in a downstsream TriBITS CMake project build.
But then what about situations where there are external packages/TPLs with dependencies like TriBITS TPLs CUBLAS and CUSPARSE depend on the TriBITS TPL CUDA? For example, Kokkos depends on the TPLs CUDA and CUSPARSE but not CUBLAS. When we build and install Kokkkos with CUDA and CUSPARSE and then try to to configure Tpetra (which needs CUBLAS) in a downstream CMake project against that external Kokkos. So when the FindTPLCUBLAS.cmake file is processed in the downstream CMake project that builds Tpetra, the CUDA::all_libs target must have already been defined. But that target will not be defined until find_package(Kokkos) is called later in the external package/TPL loop.
So that means that we can't loop over the external packages/TPLs in one loop. Instead, we need to do two loops:
- a first loop is over the external packages/TPLs that involve full TriBITS compliant
<Package>Config.cmakefiles - a second loop for the remaining standard TriBITS TPLs, like CUBLAS
So in the first loop, we only want to call find_package() for the most downstream TriBITS-complient external packages/tpls (i.e. that have no downstream TriBITS-complient external packages/tpls). Calling find_package() on just those terminal TriBITS-complient external packages/tpls will result in find_dependency() being called on all of the upstream TriBITS external packages. So by the time we are done calling find_package(), we should have all of the <Package>::all_libs targets defined in that subgraph of external packages/TPLs. So, in our Trilinos/Kokkos example above, the targets CUDA::all_libs and CUSPARSE::all_libs will be defined when find_package(Kokkos) is called.
Then on the second loop, any upstream packages processed in the first loop will will already have their <Package>::all_libs targets defined so we can generate their <Package>Config.cmake files dependencies on these upstream packages, we can call target_link_libraries() successfully. As for putting in links to upstream TPLs, we will need to use the set(<UpstreamTpl>_DIR ...) then find_dependency(<UpstreamTpl>) approach since we can't assume where the<UpstreamTpl>Config.cmake file actually is contained. This is where things start getting tricky.
Description
This PR completes the basic implementation for treating internal packages as pre-installed external packages. This completes:
in #63.
Most of the changes are related to dependency-related logic for figuring out what packages needs to be treated as external based on what packages are flagged as external packages with
TPL_ENABLE_<Package>=ON. (There are some tricky use cases related to subpackages that had to be addressed.)This includes some examples to show that it works.
Instructions for reviewers
*.cmakesource files and in the*.rstfiles. In particular, please review the GitHub rendered sections:<tplDefsDir>/FindTPL<tplName>.cmake${TPL_NAME}_FINDMODTasks
TribitsExProjConfig.cmakein the upstream package installs