EPIC: Merge TriBITS concepts and implementation of Packages and TPLs

[bartlettroscoe]

Parent Issue:

• EPIC: Initial TriBITS Modernization and Generalization #367

Child Issues:

• Provide feedback on TriBITS package dependencies data-structures #377
• Address some issues for initial implementation for treating internal packages as external (#63) #562
• Address relocatable package installs and usage of <Package>Config.cmake files #563

Blocked by:

• Move to modern CMake target-based propagation of build information #299

Description

The current design of TriBITS has TriBITS Packages and TriBITS TPLs and distinct separate entities. TriBITS Packages are always built from source in the current TriBITS design while TriBITS TPLs are always pre-built and just pointed to at configure time. This has been a successful model for Trilinos, CASL VERA, and other related projects for several years. However, this model does not scale well to larger meta-projects and does not provide sufficient flexibility to handle more efficient alternative development workflows and other use cases.

The basic idea being proposed in this story is to extend TriBITS to allow some pre-built (and possibly installed) TriBITS packages to be treated as TPLs and then configure/build some downstream TriBITS packages from source. This would be accomplished through the usage of <Package>Config.cmake files to get the needed information. Likewise, this work would allow some TPLs could be built from inside of the TriBITS project like other TriBITS packages.

The details of the of the plan, the motivating use cases, and the design implications are given in this Google Doc.

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

Remaining Tasks

• Complete Use Case 3: Configure/build pointing to a subset of already installed TriBITS packages in same repo
• ???

[nschloe]

If I may comment on this from the perspective of a (distro) package maintainer:

Every piece of software has a bunch of dependencies, in former times only listed in a README, and more recently rigorously checked at configure time.
Some projects ship third-party software (for example gmsh with the idea to make it easier for users to install the software. Unfortunately, in all cases I'm aware of, the bundled software is barely updated and doesn't encourage pushing changes upstream. This way, factual forks of the dependent libraries are created.

Constrasting this, PETSc does not bundle its dependencies, but has its (custom) build system download them for you from the appropriate source. From a package maintainer's point of view, it's not quite clear why the fetch-&-build of TPL should be part of the build system for the actual code. Because, in fact, what you're doing is the job of a distribution (dependency managment, installation etc.).

A cleaner and equally easy way helping the user install TPLs is to provide a separate script that installs all deps (e.g., install_trilinos_dependencies.sh). This way, the lazy user can use this convenience script, or install the dependencies via the distribution (e.g., apt-get install libsuperlu-dev libnetcdf-dev [...]). FEniCS goes that way.
The advantage that I see in this approach is a separation of concerns and consequently an easier-to-maintain codebase.