Move to modern CMake target-based propagation of build information

[bartlettroscoe]

Parent Issue:

• 367

Child Issues:

• 433

• 443

Blocked By: trilinos/Trilinos#8498

Description

One of the things holding back TriBITS and projects using TriBITS in accessing new features of CMake for which TriBITS still using variables to manage compiler options and include directories. This issue is to move to using:

• target_compile_definitions()
• target_compile_features()
• target_compile_options()
• target_include_directories()
• target_link_directories()
• target_link_libraries()
• target_link_options()

and to move completely to targets instead of variables for each TriBITS (internal and external) package.

This needs to be done as part of a comprehensive refactoring as part of #63.

This refactoring should implement and respect this proposed standard for <Package>Config.cmake files.

Related to:

• SEPW-214

Tasks

• [x] Add PUBLIC to target_link_libraries() in TriBITS intra-package linking
• [x] Add new library${PACKAGE_NAME}::<lib-name> targets and ${PACKAGE_NAME}::all_libs INTERFACE library targets for TriBITS packages and target_link_libraries( ... PUBLIC ... ) to define dependencies to upstream packages. (see PR #424)
• [x] Experiment with adding new ${TPL_NAME}::all_libs INTERFACE GLOBAL library targets for TPLs and use target_link_libraries( ... INTERFACE ... ) to define dependencies between TPLs.
• [x] Add include directories to all internal targets with target_include_directories()
• [x] Address problems with partial refactoring of TriBITS to modern CMake targets and get merge to Trilinos 'develop' to stick: #433
• [x] Complete refactoring of TriBITS targets to use modern CMake targets for all dependencies and managing include directories (no more using variables <Package>_INCLUDE_DIRS, <Package>_TPL_INCLUDE_DIRS, <Package>_LIBRARIES or <Package>_LIBRARY_DIRS).
• [x] Strip out all old machinery in TriBITS involving vars <Package>_INCLUDE_DIRS, <Package>_TPL_INCLUDE_DIRS, <Package>_LIBRARIES and <Package>_LIBRARY_DIRS.
• [x] Do some testing with Trilinos, Albany, Nalu, and SPARC.
• [x] Create and post new Trilinos PR to snaphsot updated TriBITS 'master' branch: https://github.com/trilinos/Trilinos/pull/10614
• [ ] Get PR https://github.com/trilinos/Trilinos/pull/10614 to merge (see Task there)

[bartlettroscoe]

CC: @mperrinel, @marcinwrobel1986, @keitat

FYI: A build problem with SPARC on the Vanguard system 'stsria' for the partial refactoring of TriBITS to use modern CMake targets in handling INTERACE_INCLUDE_DIRECTORIES has exposed a serious break in backwards compatibility in moving to modern CMake in how all IMPORTED targets include directories are handled as SYSTEM directories and included on the compile line with -isystem (which changes the search order for header files and how warnings are expressed from headers under these directories). The problem and some potential (partial) workarounds are described in the new issue #443.

From my study and analysis, it seems to be impossible to maintain backward compatibility with this TriBITS refactoring to modern CMake. It seems that CMake would need to be extended in order to return backwards compatibility. I need to consult with the Kitware CMake experts on how the advice we address this.

NOTE: Let's discuss this issue in #443 and not here.

[bartlettroscoe]

FYI: Given that the lingering TriBITS snapshot into Trilinos 'develop' in Trilinos PR #9978 breaks backward compatibility (see #443), we might as well just wait to merge #9978 and charge ahead with completing the transition of TriBITS to modern CMake targets.

[bartlettroscoe]

FYI: With the merge of #479, this is essentially done. All of the TriBITS tests pass and I tested this against Albany and Nalu (see internal tribitsrefactoring#4 and internal tribitsrefactoring#5). I will test against SPARC next and will create a new TriBITS PR if I find any other issues.

But I will put this in review.

NOTE: I will not be able to take his out of review until TriBITS 'master' is synced to Trilinos 'develop' and we get feedback from customers.

[bartlettroscoe]

FYI: I created PR trilinos/Trilinos#10614 to update the snapshot of TriBITS 'master' into Trilinos 'develop' that switches to modern CMake targets.

[bartlettroscoe]

NOTE: PR trilinos/Trilinos#10614 was just merged. I will leave this issue "In Review" for a few weeks to collect any lingering issues that may not have been caught yet. I will work very hard to help resolve issues ASAP so we don't back out upgraded TriBITS.

[bartlettroscoe]

With the merge of trilinos/Trilinos#10614 two days ago, it exposed that there were still downstream CMake projects at SNL that were generating export makefiles for Trilinos, but indirectly by looping over ${Trilinos_LIBRRAIES} (which is now just a list of namespaced targets).

[bartlettroscoe]

Below is a response to an internal Trilinos customer about supporting export makefiles. This approach really has nothing to do with TriBITS.

---

If you really want to support export makefiles, an approach that will work is outlined in:

https://github.com/TriBITSPub/TriBITS/issues/299#issuecomment-582585296 https://github.com/TriBITSPub/TriBITS/issues/299#issuecomment-828678848 https://github.com/TriBITSPub/TriBITS/issues/299#issuecomment-828692051

If supporting makefiles is critical, this is something you should take to the Trilinos Leaders and get a contactor to do. The ability to generate an export Makefile from find_package(<Package>) is really independent from TriBITS and could work for nearly any CMake-generated <Package>Config.cmake file. It is just that Kitware does not want to support such functionality.

[mathstuf]

could work for nearly any CMake-generated Config.cmake file. It is just that Kitware does not want to support such functionality.

I've done it, but it is specific to each project. One for ParaView can be seen here: https://gitlab.kitware.com/paraview/paraview/-/blob/master/Clients/CommandLineExecutables/paraview-config.in

[bartlettroscoe]

FYI: There are a few issues with the merge of trilinos/Trilinos#10614 that are covered in trilinos/Trilinos#10774. Once those issues are resolved, I think it is safe to close this issue.

[bartlettroscoe]

With the merge of Trilinos PR #trilinos/Trilinos#10930, I believe the transition to modern CMake for TriBITS and Trilinos is complete!

Closing as complete!