Exposing parts of TriBITS as CMake modules #368
Comments
|
@bartlettroscoe @keitat @fnrizzi Let's discuss the idea here or on the meeting - as you feel suitable. |
|
I have the same opinion. Lots of Tribits commands are useful. However, it needs to encapsulate all build project inside Tribits. |
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.
Technically every 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). |
Yes, let's discuss at the next meeting. |
I also make sure this does not run over top of the existing test build_docs (see comments in file).
I also make sure this does not run over top of the existing test build_docs (see comments in file).
|
The issue of naming came up in #493 (comment) that is very much related to the refactoring of TriBITS Core into smaller reusable components. |
…b#368, TriBITSPub#582) This breaks some test support related modules for the function tribits_add_test() into their own subdirectory: tribits/core/test_support/ and include them with explicit relative and absolute includes and not relying on CMAKE_MODULE_PATH. (By using explicit includes we can better see and manage the dependencies between modules on these separate subdirs and better partition TriBITS.) To cleanly break out these test_support modules, I created a new subidr: tribits/core/common/ and put the modules TribitsCMakePolicies.cmake and TribitsConstants.cmake into them. And I also did not add this new subdir to CMAKE_MODULE_PATH for the same reason as above for test_support. This allows some non-test-related modules in tribits/core/package_arch/ to depend on tribits/core/common/ but not tribits/core/test_support/. Technically, this commit is the start of the componitization of TriBITS Core as per TriBITSPub#368.
…riBITSPub#368, TriBITSPub#582) Changes to TriBITS: * Change tribits_add_advanced_test() to set explicit include of DriveAdvancedTest.cmake without setting CMAKE_MODULE_PATH. * Use more explicit includes in tribits/core/utils/*.cmake mdoules needed to get above to work. Changes to TribitsExampleProject2/Packages1: * Updated package1-prg to accept command-line arguments that are echoed to STDOUT. * Added new test Package1_Prg-advanced taking in command-line arguments using tribits_add_advanced_test() and in raw CMake build.
…riBITSPub#368, TriBITSPub#582) Changes to TriBITS: * Changed explicit includes from TribitsAddAdvancedTest.cmake (this module and its included modules will be moved to tribits/core/test_support/). * Remove option to prefix test base name in tribits_add_advanced_test() by '${PROJECT_NAME}_' (since tribits_set_tribits_package_name() is now being called to set PACKAGE_NAME give PROJECT_NAME). * Changed tribits_add_advanced_test() to set explicit include of DriveAdvancedTest.cmake without setting CMAKE_MODULE_PATH. * Use more explicit includes in tribits/core/utils/*.cmake mdoules needed to get above to work. Changes to TribitsExampleProject2/Packages1: * Updated package1-prg to accept command-line arguments that are echoed to STDOUT. * Added new test Package1_Prg-advanced taking in command-line arguments using tribits_add_advanced_test() and in raw CMake build. Changes to tests: * Removed regex for CMAKE_MODULE_PATH from driver file for tribits_add_advanced_test() (which reduces the total number of checks by 1).
…ITSPub#368, TriBITSPub#582) Changes to TriBITS: * Changed explicit includes from TribitsAddAdvancedTest.cmake (this module and its included modules will be moved to tribits/core/test_support/ in next commit). * Remove option to prefix test base name in tribits_add_advanced_test() by '${PROJECT_NAME}_' (since tribits_set_tribits_package_name() is now being called to set PACKAGE_NAME give PROJECT_NAME). * Changed tribits_add_advanced_test() to set explicit include of DriveAdvancedTest.cmake without setting CMAKE_MODULE_PATH. * Use more explicit includes in tribits/core/utils/*.cmake mdoules needed to get above to work. Changes to TribitsExampleProject2/Packages1: * Updated package1-prg to accept command-line arguments that are echoed to STDOUT. * Added new test Package1_Prg-advanced taking in command-line arguments using tribits_add_advanced_test() and in raw CMake build. Changes to tests: * Removed regex for CMAKE_MODULE_PATH from driver file for tribits_add_advanced_test() (which reduces the total number of checks by 1).
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.
The text was updated successfully, but these errors were encountered: