Exposing parts of TriBITS as CMake modules

[mzuzek]

Would it be possible and desired to decouple parts of TriBITS that are very useful on their own - like test setup (e.g. TRIBITS_ADD_ADVANCED_TEST) and ETI setup (e.g. TRIBITS_ETI_GENERATE_MACROS) - into separate [sub]modules ?

That would create an opportunity for small and medium projects to adopt parts of TriBITS as CMake library or toolkit - without the requirements posed by the framework and effort of incorporating it (i.e. just use CMake functions and macros without defining project, packages, etc.).

Technically it could be possible to extract such toolkit or library from the framework and keep the latter use the former in the original scenario when whole TriBITS framework is incorporated.

[mzuzek]

@bartlettroscoe @keitat @fnrizzi

Let's discuss the idea here or on the meeting - as you feel suitable.

[keitat]

I have the same opinion. Lots of Tribits commands are useful. However, it needs to encapsulate all build project inside Tribits.

[bartlettroscoe]

Would it be possible and desired to decouple parts of TriBITS that are very useful on their own

Yes, that is possible. The testing support code is an obvious case and, as I have said, I have already done that with a few projects and it is actually already documented here.

into separate [sub]modules

Technically every *.cmake file is CMake "module". But what we are really talking about is breaking TriBITS Core into smaller "packages" according to the Software Engineering definition of a package (see the 6 packaging principles in the book Agile Software Development). These things can be broken off into subdirs under tribits/core/ like tribits/core/test_support/ for these testing-support functions (that only depends on tribits/core/utils/ so it would be easy to snapshot out).

But at the core of TriBITS (called "TriBITS Core") is package-based architecture which is a software framework. We can try to minimize that core package-based framework as much as possible, but at some point it will not be possible to shrink it more without loosing that core packaging functionality. (If you don't care about packaging of and managing internal dependencies of a large amount of CMake software, then you should just be using a CMake macro wrapper package like BLT that makes no attempt to try to manage the internal dependencies.) TriBITS is less overhead and is a faster and simpler solution than something like Spack or even CMake ExternalProject for dealing with packaging of CMake-based software. (I was just at a meeting yesterday in ECP where people are supposed to be using Spack but they just said there was too much of a learning curve to figure out how to just configure and re-build one little piece of software iteratively using Spack so there were building everything by hand. With TriBITS, it is easy to iteratively rebuild software.)

With that said, there is a lot of things that TriBITS Core is currently doing, like managing global compiler options, that can and should be stripped out. The challenge is how to trim down and refactoring TriBITS to be more lean and mean without making big breaks in backward compatibility.

So please make any other suggestions you see about how to break out useful functionality in TriBITS as reusable components.

(Related to my epic SEPW-214, PLEASE IGNORE).

[bartlettroscoe]

Let's discuss the idea here or on the meeting - as you feel suitable.

Yes, let's discuss at the next meeting.

[bartlettroscoe]

The issue of naming came up in https://github.com/TriBITSPub/TriBITS/pull/493#discussion_r921290889 that is very much related to the refactoring of TriBITS Core into smaller reusable components.