xsdk-project / xsdk-issues

A repository under which GitHub issues not related to a specific xSDK repo can be filed.
7 stars 0 forks source link

datatransferkit build error. #214

Closed balay closed 10 months ago

balay commented 11 months ago

I guess we need to figure out the correct kokkos/trilinos/datatransferkit dependency here

spack-build-out.txt

ref: ./bin/spack install -j32 xsdk@1.0.0

trilinos:     version("14.4.0", branch="develop")
datatransferkit:      version("3.2", branch="master", submodules=True)
-- linux-rocky9-cascadelake / gcc@11.3.1 ------------------------
kokkos@4.1.00
==> 1 installed package
masterleinad commented 11 months ago

This should now work after merging https://github.com/ORNL-CEES/DataTransferKit/pull/603.

balay commented 11 months ago

I'm still seeing issues.

spack-build-out.txt

jwillenbring commented 11 months ago

@bartlettroscoe Do you have any input on this? DTK is not finding Trilinos properly because it thinks that Kokkos is not enabled.

masterleinad commented 11 months ago
[...]
-- Enabled Kokkos devices: SERIAL
CMake Error at cmake/TPLs/FindTPLTrilinos.cmake:1 (FIND_PACKAGE):
  Found package configuration file:

    /data/balay/spack.x/opt/spack/linux-rocky9-cascadelake/gcc-11.3.1/trilinos-14.4.0-qjr73prj73lq5qo735s3s4xz3ywkchql/lib/cmake/Trilinos/TrilinosConfig.cmake

  but it set Trilinos_FOUND to FALSE so package "Trilinos" is considered to
  be NOT FOUND.  Reason given by package:

  ERROR: Could not find component 'Kokkos'!
[...]
bartlettroscoe commented 11 months ago

@masterleinad, @jwillenbring, and @balay, the issue that that Kokkos is now being treated as an external package so it is no longer a proper internal "component" of Trilinos. So it is really not technically correct to list Kokkos as one of the components of Trilinos.

I can think of a few different possible solutions here:

Option-1: Since DTK is using Tpetra just list Tpetra in COMPONENTS and leave out Kokkos since if you have Tpetra, you automatically have Kokkos. (This would require changing any downstream CMake project that calls find_package(Trilinos COMPONENTS ... Kokkos ...).)

Option-2: Extend TriBITS to allow the COMPONENTS list passed to find_package() to contain both internal and external components. (This require patching TriBITS and putting out a Trilinos 14.4.1 patch release but would not require any changes to downstream CMake projects.)

Option-3: Have DTK and other downstream Spack packages stop calling find_package(Trilinos COMPONENTS Kokkos Tpetra <pkgi> ...) and instead call find_packag(Kokkos), find_package(Tpetra), find_package(<pkgi>). (This would require changing any downstream CMake project that calls find_package(Trilinos COMPONENTS ... Kokkos ...).)

My advice would be to choose option-3. That is backward compatible to older versions of Trilinos and it starts to move the package ecosystem away for a Trilinos-centric world. (It should just be that different Spack packages provide different subsets of Trilinos packages as installed CMake packages with installed <Package>Config.cmake files. Trilinos should be a coordination project and provide for very efficient co-development workflows but one should stop assuming that "Trilinos" will be one big installed CMake meta-package called "Trilinos".)

But, of course, option-2 would require no changes to downstream customers so it may be the preferable option (but it also hides what is actually happening and is elevates "Trilinos" as a delivery mechanism for compatible packages).

I am okay with any of these options. Just let me know what people want to do and we can make it happen :-)

jwillenbring commented 11 months ago

My advice would be to choose option-3. That is backward compatible to older versions of Trilinos and it starts to move the package ecosystem away for a Trilinos-centric world. (It should just be that different Spack packages provide different subsets of Trilinos packages as installed CMake packages with installed <Package>Config.cmake files. Trilinos should be a coordination project and provide for very efficient co-development workflows but one should stop assuming that "Trilinos" will be one big installed CMake meta-package called "Trilinos".)

I like this option for the reasons Ross expressed. I am curious to see what others think too.

masterleinad commented 11 months ago

@balay Can you please try again?

balay commented 11 months ago

@masterleinad I'm still seeing issues. Attaching the log

spack-build-out.txt

balay commented 10 months ago

@masterleinad works now. Thanks!