Build and install downstream Trilinos packages against pre-installed KokkosKernels and SEACAS using their native CMake build systems

[bartlettroscoe]

@lucbv, @crtrott, @rppawlo, @ndellingwood, @ibaned, @sebrowne, @jwillenbring

Description

Now that Kokkos 4.1 has been snapshotted into Trilinos 'develop' with the merge of PR #11988 the next step (other than waiting for Kokkos 4.1 to be released) is to get the native non-TriBITS CMake build system for KokkosKernels to be updated so that KokkosKernels can be pre-installed and build the rest of Trilinos against it.

This issue can also cover testing with the independent install of SECAS as well as would be done by Spack. (But since SEACAS is just using TriBITS, that should be pretty easy.)

[bartlettroscoe]

@ndellingwood and @lucbv,

Given that the release-candidate-4.1.00 branch in the KokkosKerenls GitHub repo is very new, could I consider patching the KokkosKernels CMake build system in the release-candidate-4.1.00 release branch and getting it to work with TriBITS? I think that just adding a KokkosKenels::all_libs target to the installed KokkosKerenlsConfig.cmake file.

What say you?

[ndellingwood]

Given that the release-candidate-4.1.00 branch in the KokkosKerenls GitHub repo is very new, could I consider patching the KokkosKernels CMake build system in the release-candidate-4.1.00 release branch

@bartlettroscoe it would be better to patch to develop since the release-candidate-4.1.00 branch is no longer active nor maintained now that the 4.1 release PR's have merged

[bartlettroscoe]

@ndellingwood,

How is the 4.1 release managed? Is a branch not created for the 4.1.z release series?

[ndellingwood]

Is a branch not created for the 4.1.z release series?

@bartlettroscoe 4.1.z will be branched off the master branch (which contains the merge of the release-candidate-4.1.00 branch). If you submit changes to develop, we will cherry-pick to the 4.1.01 branch

[bartlettroscoe]

@ndellingwood, @crtrott, @dalg24

@bartlettroscoe 4.1.z will be branched off the master branch (which contains the merge of the release-candidate-4.1.00 branch). If you submit changes to develop, we will cherry-pick to the 4.1.01 branch

Just an FYI, but the version identifier 4.1.01 is not consistent with the Semantic Versioning Standard (https://semver.org/#spec-item-2):

2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

Instead, it should be 4.1.0 and 4.1.1.

[dalg24]

This is a sore point. As far as I know, no one in our team likes the 4.X.0Y scheme, but we decided we would stick with it for the 4.X series (in the name of consistency).

[bartlettroscoe]

It would seem that the SPARC team would like to have this capability for their custom Spack trilinos/package.py file.