a simple CMake project compiles sources only when out-of-date, target are linked only when dependers are out-of-date. IIRC unit tests and integration tests are always run, which makes sense to me because a test may not directly depend on a target.
External projects are different, because they are treated as a self-contained unit. A common use is to drive the external project’s pipeline only once. Another option is to always build the project to bring it up-to-date. The test phase is always driven.
In the second scenario it would be beneficial to drive the test phase only when the external project is brought up-to-date, I think.
ExternalProject_Add can drive the pipeline for another CMake project. Among the default steps there is test and install:
ExternalProject_Add(foo
BUILD_ALWAYS ON
TEST_BEFORE_INSTALL TRUE
)
For a simple project the targets test and install are always out-of-date, meaning that the commands for these targets are always executed.
For an external project i wonder if it makes sense for these targets to bring up-to-date, meaning that the commands for these targets are only executed once to bring them up-to-date.
We can skip the test step with the superbuild. If we choose not to the tests are run every time the superbuild is build. When the build for the external project didn’t change, why repeat the test and install steps? When BUILD_ALWAYS is ON, test could depend on build and the time-stamp based method.
Update: i think i know the answer to my question - the superbuild cannot know if the build target is up-to-date, or not. For that it would need to know the output products of the build step.
Ah, I forgot about that option. But yes, the build step cannot be known whether it is out-of-date or not in general. I think “no-op rebuilds are fast” is the assumption there, but running a test suite does indeed cause trouble there.