Hello,
Starting from issue Make Optional26 Packageable · Issue #28 · beman-project/Optional26 · GitHub proposed by @bretbrownjr , I created a PR to implement that - Split build production vs testing by neatudarius · Pull Request #29 · beman-project/Optional26 · GitHub.
@Sdowney , suggested that this may be not a good idea in the end, due to silent breaks.
I would like to discuss both options here and to get an agreement. Maybe add this topic to our weekly sync agenda - CC: @dsankel .
I think it’s OK to have a production only build and a full-tree build (and run tests). We can run both tasks from CI, if needed.
Anyways, I am not opposing to any convention. My proposal is to guide this thread into a Beman Standard requirement!
I advocate for portable and reliable tests (for standard library testing… probably all of them?) to be built and added to ctest by default. The general principle is to always make the right thing the easy thing, and we want all tools and humans to run tests whenever possible. That includes important testing for libraries with lots of logic in their header files… linking representative programs to force the linker to find declaration or build configuration mistakes.
If we are consistent in using include(CTest) and we guard any testing specific builds and other actions behind conditionals on BUILD_TESTING, builders of the projects can turn off test builds and runs as needed. Generally it shouldn’t be, but some packaging systems do track test dependencies separately and there are workflows to support builds that do not test sometimes.
production vs testing
This is sensible to me and also common practice IME.
silent breaks
This seems like an unlikely outcome to me.
This has been added to today’s weekly sync agenda.
A quick Google search didn’t reveal how to allow tagging of users for reviewers. I wouldn’t worry about it though as I think we all get emails for every PR on this repository.
I’m late to the party and some of that was discussed in the last weekly: However it is done, I think it is crucial that there is a way using one or more Beman projects as part of another project without running the tests in the dependant packages each time a build of the depending package is done! For example, if I’m developing a Depending using Optional26, it is fine when the Optional26 tests are built and run once but it is not acceptable having to run the tests each time I make a change and test Depending. While the test for Optional26 may run quickly, depending on multiple such projects or bigger projects just becomes a nuisance without any benefit.
I could imagine a cmake flag, say cmake -DBEMAN_ONLY_TEST=self disabling tests of dependent projects: the easy way to build wouldn’t specify the argument and tests are run. I’m not a cmake expert and something else may be more appropriate. I do believe that functionality is essential and it should be obvious and reasonably easy to do.
1 Like
At the last sync up it was identified that CMake already has this functionality so we don’t need to do much to enable it.
-
If you’re incorporating a Beman project using add_subdirectory, you can do this:
block()
set(ENABLE_TESTING FALSE)
add_subdirectory(3rdparty/Optional26)
endblock()
-
If you’re using FetchContent, you can use the EXCLUDE_FROM_ALL keyword with FetchContent_Declare.
@neatudarius’s latest PR to the Beman standard includes wording that’ll ensure tests will not be built in Beman libraries when one of the above two strategies are used to ingest the library.
You can also specify EXCLUDE_FROM_ALL on the add subdirectory call, and only the targets you explicitly add as dependencies will be pulled into the build graph. This should be the normal way to vendor in a library in tree with cmake. This is also much friendlier to disconnected development, especially since the reliable way of getting initial configure is to delete the build directory.
https://cmake.org/cmake/help/latest/command/add_subdirectory.html
1 Like