Trilinos: export modern targets

[sethrj]

Enhancement

@bartlettroscoe

Currently Trilinos uses TriBITS to export CMake config files (with the Trilinos_ENABLE_INSTALL_CMAKE_CONFIG_FILES option). However, these files only generate simple library targets (not global, not namespaced) and do not propagate build flags or include directories. As a workaround, ForTrilinos and SCALE use an independent FindTrilinos.cmake module that extends the tribits-exported components (attached below).

It would make including Trilinos easier for downstream CMake projects if global, scoped targets were exported natively by the FindTrilinos module. Another enhancement would be to export other Trilinos configuration-related variables, e.g. Tpetra_INST_INT_LONG_LONG.

include(FindPackageHandleStandardArgs)

# Load any installed $TRILINOS_ROOT/lib/cmake/Trilinos/TrilinosConfig.cmake
find_package(Trilinos QUIET NO_MODULE)

if(Trilinos_FOUND AND NOT TARGET "Trilinos::Trilinos")
  # Add base-level trilinos includes
  add_library(Trilinos::Trilinos INTERFACE IMPORTED)
  target_include_directories(Trilinos::Trilinos SYSTEM INTERFACE
    "${Trilinos_INCLUDE_DIRS}"
    )

  set(_components "${Trilinos_FIND_COMPONENTS}")
  if(NOT _components)
    # Set to variable leaked by TrilinosConfig.cmake with all top-level
    # packages.
    set(_components "${COMPONENTS_LIST}")
  endif()

  foreach(_comp IN LISTS _components)
    if(NOT Trilinos_${_comp}_FOUND)
      continue()
    endif()
    # We want to provide targets based on component names, but Trilinos only
    # makes targets with the lowercase library names. We can't use ALIAS because
    # Trilinos also fails to declare the targets as GLOBAL. A solution is to
    # declare our own scoped library and use interface dependencies to link
    # against the first library name for that component.
    add_library("Trilinos::${_comp}" INTERFACE IMPORTED)

    # Link library against the Trilinos-created target and the main Trilinos
    # target (for include dirs/flags)
    list(GET ${_comp}_LIBRARIES 0 _lib)
    target_link_libraries("Trilinos::${_comp}"
      INTERFACE Trilinos::Trilinos "${_lib}")
  endforeach()
  unset(_components)
  unset(_comp)
  unset(_lib)
endif()

find_package_handle_standard_args(
  Trilinos HANDLE_COMPONENTS
  REQUIRED_VARS Trilinos_INCLUDE_DIRS Trilinos_LIBRARY_DIRS Trilinos_LIBRARIES
  VERSION_VAR Trilinos_VERSION
)

[bartlettroscoe]

@sethrj, yup, that is the plan. See:

• https://docs.google.com/document/d/19gIZgPAfnK7RTdh0sMKr5Yeo1epPVKIfona-oxoCtsg/edit

This will be done as part of https://github.com/TriBITSPub/TriBITS/issues/299.

Also see discussion on this in:

• https://gitlab.kitware.com/snl/project-1/-/issues/139

But for greater flexibility, I think you want to find individual packages like find_package(Tpetra), find_package(MueLu) instead of find_package(Trilinos COMPONENTS Tpetra Muelu ...). The former allows Tpetra and MueLu to be built and installed in independent CMake projects (i.e. different Spack packages) and the latter does not.

[sethrj]

Sounds good!

[bartlettroscoe]

Sounds good!

@sethrj, please comment on:

• https://docs.google.com/document/d/19gIZgPAfnK7RTdh0sMKr5Yeo1epPVKIfona-oxoCtsg/edit

if you see any needed changes to that proposal.

If we can get CMake projects to adopt that standard, then we can make it easier to stitch together different CMake projects without having to read the detailed documentation for each project independently to figure out how to link to them after finding them.

[sethrj]

With this issue, I was hoping that the basic "modern target" for export would be a separate (and easier) component compared to refactoring all of tribits' internal system.

[bartlettroscoe]

Another enhancement would be to export other Trilinos configuration-related variables, e.g. Tpetra_INST_INT_LONG_LONG.

Right. Exporting variables like Tpetra_INST_INT_LONG_LONG in TpetraCore.cmake (and therefore TpetraConfig.cmake and TrilinosConfig.cmake) is also necessary to be able to build and install Trilinos packages in smaller subsets.

[github-actions[bot]]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[github-actions[bot]]

This issue was closed due to inactivity for 395 days.