Kokkos library names in Kokkos and Trilinos

[kddevin]

Just curious:

Why does Kokkos use different library names if I build it in Trilinos vs building it in Kokkos?

When I build Kokkos directly, I get libkokkos.a.
When I build Kokkos as part of Trilinos, I get
libkokkosalgorithms.a libkokkoscore.a libkokkostsqr.a
libkokkoscontainers.a libkokkoskernels.a

This feature makes it difficult to interchange stand-alone Kokkos and Kokkos-in-Trilinos to build an external application. If this is Trilinos' problem, let me know; I'll take the question there.

Thanks.

[mhoemmen]

Does "build Kokkos directly" mean "use Kokkos' Makefile-based build system"?

[kddevin]

Yes.
${KOKKOS}/generate_makefile.bash
--kokkos-path=${KOKKOS}
--prefix=${INSTALL}
--with-serial

[mhoemmen]

This feature makes it difficult to interchange stand-alone Kokkos and Kokkos-in-Trilinos to build an external application.

Trilinos does not promise a standard set of libraries. Users are supposed to draw the ordered list of libraries from the ${PACKAGE}_LIBRARIES variable, defined in each of the following two installed files:

• Makefile.export.${PACKAGE} file (for a Makefile-based build system)
• lib/cmake/${PACKAGE}/${PACKAGE}Config.cmake (for a CMake-based build system)

I don't think a TriBITS library can cross package boundaries. Changing Kokkos from a collection of subpackages into a single package would break backwards compatibility. It is possible, however, to combine several static libraries into one.

[crtrott]

In the spirit of what Mark asked, do you actually hard-code your library list? We don't actually guarantee a specific name. What is guaranteed are the GNU and CMake variable names you are supposed to use. Also there is an option for the pure CMake build to build separate libraries instead of one. But I am not sure that we ever test that.

[crtrott]

And as Mark said: we main issue on the Trilinos side is that you kinda have to split libraries by sub package, and we made sub packages since we wanted to give people the option not to link in or use algorithms and containers. While this isn't a super big deal for any people I know off, it has the added advantage of keeping our internal dependencies honest.

[kddevin]

The library list is hard-coded for me in the application. I am building a tool (Genten) that is build on Kokkos. It can be built with Kokkos snapshotted into its source directory, or with an already installed Kokkos.

My first attempt tried to use the Kokkos in Trilinos, which is where I discovered the difference in library names. My intent was to ensure I was using the same version of Kokkos for comparisons between genten and a Trilinos-based tensor code. I gave up and snapshotted Kokkos.

Even if I remove Genten's hardcoded libkokkos.a, there are more inconsistencies that would prevent Genten from using Trilinos' build easily:

• Makefile.export.Kokkos in Trilinos/BUILD/packages/kokkos defines variable Kokkos_LIBRARIES and includes the subpackages libraries (-lkokkoscore, etc.); it claims KOKKOS_LIBS is deprecated.
• Makefile.kokkos created in Trilinos/BUILD defines KOKKOS_LIB as -lkokkos -ldl; it does not have the subpackage libraries.
• Makefile.kokkos in the Kokkos distribution defines KOKKOS_LIBS with -lkokkos.

So an application like genten can't really use the kokkos in Trilinos without major hacking of some of these files. Maybe fixing Trilinos' generated Makefile.kokkos would work? I don't know the purpose of these different files in Trilinos.

[crtrott]

Yeah. This is a bug in the generated Makefile.kokkos inside of Trilinos.

[crtrott]

A Makefile.kokkos installed by Trilinos (or cmake) needs to contain the right KOKKOS_LIBS arguments, depending on whether the sub packages were build separately.

[jjwilke]

This speaks to ... unnecessary... challenges with Trilinos. Kokkos really needs to be spun off as a TPL. Generally speaking, everything in Trilinos at the very least should be supported as either an internal package or a TPL.

I should be able to hack this for now by having Kokkos always install a kokkosConfig.make - EVEN when installed with Trilinos. For non-Tribits things using Kokkos as a TPL, this will provide a function:

FIND_PACKAGE(kokkos)
....
TARGET_LINK_KOKKOS(myTarget)

The details of the exact list of libraries and names will not be necessary.

[dalg24]

Related to #2295 and #2119

[masterleinad]

Addressed in #2447.