I want to make sure that the targets I export and install are set up correctly. Running the test suite against both the in-tree build and installed version would solve that nicely. Is there a known pattern for this? Something similar to autotool’s distcheck?
Nothing exists right now. The project needs to be set up to consume an external project and then build/run its test suite. CMake does it for tests that use the binaries via its CMake_TEST_HOST_CMAKE variable. VTK has its Testing/External directory that finds VTK then builds and runs the tests against it.
I thought there was an issue for this, but I can’t find it right now. @robert.maynard Do you have that issue link handy?
I don’t think I ever filled a formal bug / feature request for this. I only had a draft up on my whiteboard.
I think I’m doing something similar (using a second, separate “examples” project within the same repo) here and in other projects the same way. I have the CI build and install, then have a separate Examples/ directory with a project that either uses the main project’s build/ directory exports or installed project:
h5fortran/CMakeLists.txt at main · geospace-code/h5fortran (github.com)
h5fortran/ci.yml at main · geospace-code/h5fortran (github.com)
That isn’t one “distcheck” like you wanted or the single superproject-like structure Ben suggests, but does test the same aspects of main project export/install. The reason I took this approach was to avoid adding CMake test code to the main project, but I think it’s up to dev/project preferences.
As it happens, I’m doing something very similar in Qt6 at the moment as well. Started out implementing building of examples as test cases using cmake --build-and-test, but following discussions with developers, it was decided to add them as ExternalProject sub-projects in the main build instead. It means you have to exclude them from the default all target and you take on the responsibility of doing an install before you try to build the examples, or alternatively you export() the necessary things into your build tree and point your examples there instead of an install area - the dependencies also need to be set up carefully to ensure everything needed by the examples have been built. If you want to see the gory details, you can follow along the review of the changes in gerrit. Just be aware the Qt has some complex cases to handle that probably won’t apply to most projects, so that adds to the complexity you see there.
I moved VTK and ParaView’s examples to be run by the test suite. It ensures they’re run at the right time (in a normal workflow) and instead of checking dependencies at configure time, the tests can skip if they don’t find what they need (with a chance of false positives, but that’s far better than trying to keep the configure and example in sync).