Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

datatransferkit build error. #214

Closed
balay opened this issue Aug 3, 2023 · 9 comments · Fixed by ORNL-CEES/DataTransferKit#604 or ORNL-CEES/DataTransferKit#605
Closed

datatransferkit build error. #214

balay opened this issue Aug 3, 2023 · 9 comments · Fixed by ORNL-CEES/DataTransferKit#604 or ORNL-CEES/DataTransferKit#605

Comments

@balay
Copy link
Member

balay commented Aug 3, 2023

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
Copy link
Member

This should now work after merging ORNL-CEES/DataTransferKit#603.

@balay
Copy link
Member Author

balay commented Aug 16, 2023

I'm still seeing issues.

spack-build-out.txt

@jwillenbring
Copy link
Member

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

@masterleinad
Copy link
Member

[...]
-- 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
Copy link
Member

bartlettroscoe commented Aug 17, 2023

@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
Copy link
Member

jwillenbring commented Aug 17, 2023

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
Copy link
Member

@balay Can you please try again?

@balay
Copy link
Member Author

balay commented Aug 23, 2023

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

spack-build-out.txt

@balay
Copy link
Member Author

balay commented Aug 24, 2023

@masterleinad works now. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment