phist build issue

[balay]

trilinos/kokkos dependency issue?

spack-build-out.txt

[jthies]

Thanks, Satish. This is due to evolving interfaces in Tpetra/Kokkos, I have to check if there is an easy fix.

[jthies]

Hi @balay -- I hope to have fixed it in phist@develop, once you confirm the fix I'll tag phist@1.12 for the next xSDK release.

[balay]

Sorry for the delayed response. I'm still seeing build failures.

spack-build-out.txt

[jthies]

Hi Satish, this looks different -- cmake doesn't find the KokkosConfig.cmake file. I suspect that you are building kokkos as a separate package whereas I just have trilinos+tpetra as a dependency and assume that that gives me the right CMAKE_PREFIX_PATH for kokkos, too. I could add a dependency on Kokkos in case Trilinos is built without Kokkos, is that the way to go?

[balay]

Yes - I think this is a change in "trilinos@14.4.0:" - @jwillenbring can confirm

[balay]

Sorry - just realized that phist (1.2.0) was not added to https://docs.google.com/spreadsheets/d/1KqmVyE7QXKuadaQf8-5EiLOwXhuQV67g83743aAJk0w/edit#gid=0 - so somehow phist-1.11.2 was getting installed

will add in 1.12.0 [for master branch] and recheck

[balay]

Ok - same kokkos dependency issue with 1.2.0/master

spack-build-out.txt

[jwillenbring]

@jthies Please see the discussion in #214. Does this help? Do you have an opinion on which approach is best?

[jthies]

yes, helps a little. In fact, phist uses "Option 3" discussed there already, except that the spack package assumes kokkos is in Trilinos, and if it isn't, the CMAKE_PREFIX_PATH is not set correctly. So I could roughly add a denpends_on('kokkos') when '^kokkos' in spec['trilinos'] (have to work on the syntax there, I with a when-clause that figures out know)

[bartlettroscoe]

except that the spack package assumes kokkos is in Trilinos, and if it isn't, the CMAKE_PREFIX_PATH is not set correctly.

@jthies, are you saying that Spack does not append paths to CMAKE_PREFIX_PATH for indirect dependencies? For the CMake package ecosystem to work correctly, Spack has to append paths to CMAKE_PREFIX_PATH for every enabled upstream package in the package graph. This is actually a very important issue in order for things to work in a reasonable way.

[jthies]

well, I don't want to make claims here, but from the output Satish posted it looks like it. I didn't try to build this setup myself, though. I'll try to do that.

[bartlettroscoe]

@jthies, if you run the configure of phist with --debug-find-pkg=Kokkos, CMake will tell you where it is looking. (Don't know if Spack will allow you to set that configure option or not.)

[jthies]

Hm, CMAKE_PREFIX_PATH is passed correctly (I could set CMAKE_FIND_DEBUG_MODE=ON), so it's probably my cmake code proposing to look for Kokkos in the Trilinos directory. I'll see if I can fix it. I suspect that I enforced this behavior before to avoid finding other (incompatible) installations of packages.

[bartlettroscoe]

Hm, CMAKE_PREFIX_PATH is passed correctly (I could set CMAKE_FIND_DEBUG_MODE=ON), so it's probably my cmake code proposing to look for Kokkos in the Trilinos directory.

@jthies, I think this is spelled out in the book "Professional CMake" in section "Finding Packages", but I think the best way to deal with find_package(<SomeExternalPkg>) is to allow the customer that configures your CMake project to determine how <SomeExtenralPkg> is found. (That is usually done by prepending the search directory to CMAKE_PREFIX_PATH or by setting <SomeExtenralPkg>_ROOT to be more specific, see find_package().) That way, they can resolve any issue there may be and your project does not need to be bothered with the details of how it is found. (But there are some special cases where you want to be explicit about where to look for a package like in a package's installed <Package>Config.cmake file. For example, see cmake #24378.)

Hopefully this will be easy to solve.

[jthies]

@balay, for e it builds now after a small fix. Please try phist@develop (phist@1.12.0 is there but not in spack) My previous policy was to only allow Trilinos packages to be searched for in Trilinos_DIR, now I check that first and then if needed do a second try without the restriction. I had bad experience giving CMake complete freedom before, for instance, if there is a custom and an Ubuntu installation and the custom one misses some packages, cmake might find them in /usr and mess up.

[bartlettroscoe]

I had bad experience giving CMake complete freedom before, for instance, if there is a custom and an Ubuntu installation and the custom one misses some packages, cmake might find them in /usr and mess up.

@jthies, the user should be able to sort that out by setting the directories in CMAKE_PREFIX_PATH in the correct order, and in some extreme cases, set <PackageName>_ROOT as env or CMake cache vars. This should not be so hard.

[balay]

@jthies attaching the build log

spack-build-out.txt

[jthies]

Hi @balay sorry about that. I'm a bit confused because I see that you are building phist-1.12.1, but the latest tag I have in the repo is 1.12.0. Is this perhaps a version you added to your spack for testing, and is it up-to-date with phist@develop?

[balay]

@jthies Sorry - I had this version set to master branch [I think - because https://bitbucket.org/essex/phist/branches/ listed it as the primary branch] - and forgot to verify master vs devel - when you suggested the fix is in phist@develop

Now using devel branch - I do get a successful build.

==> Installing phist-1.12.1-tgcy35iwcxppdwra5tgr2zs7gtxtw24f [78/84]
==> No binary for phist-1.12.1-tgcy35iwcxppdwra5tgr2zs7gtxtw24f found: installing from source
==> Ran patch() for phist
==> phist: Executing phase: 'cmake'
==> phist: Executing phase: 'build'
==> phist: Executing phase: 'install'
==> phist: Successfully installed phist-1.12.1-tgcy35iwcxppdwra5tgr2zs7gtxtw24f
  Stage: 3.64s.  Cmake: 5.99s.  Build: 1m 1.36s.  Install: 0.09s.  Post-install: 0.10s.  Total: 1m 12.16s
[+] /data/balay/spack.x/opt/spack/linux-rocky9-cascadelake/gcc-11.3.1/phist-1.12.1-tgcy35iwcxppdwra5tgr2zs7gtxtw24f

balay@xsdk:/data/balay/spack.x>git diff origin/develop... var/spack/repos/builtin/packages/phist/package.py
diff --git a/var/spack/repos/builtin/packages/phist/package.py b/var/spack/repos/builtin/packages/phist/package.py
index 62b8b131d4..6e7eb18ba0 100644
--- a/var/spack/repos/builtin/packages/phist/package.py
+++ b/var/spack/repos/builtin/packages/phist/package.py
@@ -34,6 +34,7 @@ class Phist(CMakePackage):
     version("develop", branch="devel")
     version("master", branch="master")

+    version("1.12.1", branch="devel")
     # compatible with python@3.11: and cray-libsci as BLAS/LAPACK provider
     version("1.11.2", sha256="e23f76307c26b930f7331a734b0a864ea6d7fb4a13c12f3c5d70c2c41481747b")

[jthies]

Thanks, @balay! I sync'd master and develop now and created a spack PR for phist@1.12.0 to be included: https://github.com/spack/spack/pull/39616

[balay]

For some reason I assumed that a new release phist-1.12.1 - would be spun from devel branch - and was using it for xsdk testing.

I've now switched over to using phist-1.12.0 release