CMake Import Issue

[ldowen]

Find package on Trilinos

Is there documentation on how to properly import Trilinos components into a separate library using CMake? I see some stuff here https://github.com/trilinos/Trilinos/blob/master/demos/simpleBuildAgainstTrilinos/CMakeLists.txt but it looks out of date. My issue is that I can run find_package(Trilinos REQUIRED COMPONENTS ShyLU Belos Tpetra Teuchos TeuchosCore) and I include the Trilinos::all_selected_libs target as a dependency for my internal libraries but it does not work. Firstly, the Trilinos include directory is not included for any of the Trilinos interface targets so it can't find it's own headers. If I fix that by explicitly setting it I still get a compile error that it cannot find a Kokkos header from Teuchos_ScalarTraits.hpp. I might be able to solve this by doing find_package on Kokkos and then setting my targets to depend on Kokkos, but that seems wrong because I do not depend on Kokkos directly. Is there something I am missing here?

[jhux2]

@trilinos/framework @bartlettroscoe Can you advise?

[ldowen]

I believe this issue could be resolved by including something similar to

target_include_directories(Trilinos::all_libs SYSTEM INTERFACE ${Trilinos_INCLUDE_DIRS}
$<TARGET_PROPERTY:Kokkos::all_libs,INTERFACE_INCLUDE_DIRECTORIES>
$<TARGET_PROPERTY:KokkosKernels::all_libs,INTERFACE_INCLUDE_DIRECTORIES>)

Or probably better to include the Kokkos includes specifically on components that use Kokkos/KokkosKernels instead of all of them. This would allow projects that bring in Trilinos to simply use find_package on Trilinos.

[sebrowne]

I'm out of town at the moment but I believe the short answer here is find_package(Trilinos COMPONENTS <packageName1> <packageName2> ) is the OLD way of including Trilinos packages. Better to do find_package(<packageName1>) find_package(<packageName2) and then point at the targets per-package that you need (e.g. Tpetra::all_libs).
I would be completely unsurprised to find that our documentation is out-of-date and I can look at updating it soon (I've been asked to update our build information as well, so this would be sensible to update at the same time)

If you do it this way, Teuchos targets should automatically have a propagated dependency on Kokkos targets (and all other appropriate dependencies).

[bartlettroscoe]

@ldowen, see the example:

https://github.com/trilinos/Trilinos/tree/master/demos/simpleBuildAgainstTrilinos
https://github.com/trilinos/Trilinos/blob/master/demos/simpleBuildAgainstTrilinos/CMakeLists.by_package.cmake

This should be getting tested automatically when the rest of Trilinos is tested (see tests with "TrilinosInstallTests_simpleBuildAgainstTrilinos" in the name). See:

https://github.com/trilinos/Trilinos/tree/master/packages/TrilinosInstallTests

And it looks like all of those tests are running in PR testing (as shown on a CDash site you likely still can't see ☹️).

[ldowen]

Thanks for getting back to me. I am confused that the CMakeLists.cmake file in that directory contains the out of date logic and the CMakeLists.by_package.cmake is the up to date logic. After trying this method, it still did not work for me for the same reason. In my case, I am bringing in the Belos and Tpetra packages (and I tried bringing in Teuchos just in case) and my compiler hits an error that Kokkos_Core.hpp cannot be found. I still had to make the targets include the Kokkos and KokkosKernel directories. I must be doing something wrong on my end if your tests are showing this sort of thing working.

[bartlettroscoe]

I am confused that the CMakeLists.cmake file in that directory contains the out of date logic and the CMakeLists.by_package.cmake is the up to date logic.

Well, unless something has changed, using find_package(Trilinos ...) is not currently considered best practice for several reasons but it should still work and it should still be supported.

The example:

• https://github.com/trilinos/Trilinos/blob/master/demos/simpleBuildAgainstTrilinos/CMakeLists.txt

is calling:

find_package(Trilinos REQUIRED COMPONENTS Teuchos Tpetra)

which should be calling find_package(Kokkos REQURIED) (or find_dependency(Kokkos REQURIED)) implicitly. The automated tests based on that file are passing, so it must be the case that the Kokkos targets are getting pulled in, or that would not work.

It should be easy to verify that the KokkosConfig.cmake file is getting processed. Just look at the installed <Package>Config.cmake files to see the recursive find calls. And you could put in temp message() statements in the installed <Package>Config.cmake to show what is getting called. If the KokkosConfig.cmake file is getting processed but the correct target properties are not getting set, that is a different story.

What is your exact use-case? Are you building Kokkos as part of Trilinos or pre-installing Kokkos and then building Trilinos against the pre-installed Kokkos? It should not matter, but who knows with these things.

[ldowen]

I am using a separate Kokkos installation so it could be that I am not doing that correctly. One other odd aspect is that we are building object libraries, which seem to use different logic when it comes to dependencies, so that might be the issue as well.

[bartlettroscoe]

@ldowen, it should be fine to pre-install Kokkos and then configure Trilinos with TPL_ENBLE_Kokkos=ON and it will find the installed Kokkos. I have never used object libraries in CMake so I don't know the rules for propagating target properties to object files but one would hope it should be the same as if these object files were part of a library.