Follow-up from "cmake: Fix installed files"
The following discussion from !155 (merged) should be addressed:
-
@smcv started a discussion: This is a nice idea, and I appreciate the effort to get this tested, but I don't think it really scales: each build takes a significant time, and adding two extra builds per feature could quickly become extremely time-consuming. If a Gitlab-CI build ends up doing multiple variant builds one after the other in a shell script loop, Gitlab can't parallelize them, so we'd end up waiting for a long time for success/failure feedback from the CMake build.
Also, just checking that they compile without also running their tests doesn't seem great, and this feature seems confusingly similar to the
ci_variant
that we already have for Autotools.If we want to test additional configurations under CMake, the way to do that is to add more
ci_variant
builds to.gitlab-ci.yml
, and include those configurations in them (they should probably be off-by-default to avoid using excessive CI resources, and we can trigger them manually when needed). For example, with Autotools, theproduction
(default),debug
,reduced
andlegacy
variants each use different options. We don't have individual variants for each feature, because it doesn't scale - we bundle a lot of optional features being enabled intodebug
, and we bundle a lot of optional features being disabled intoreduced
.At the moment the CMake part of
tools/ci-build.sh
doesn't support variants at all. If you want to add something like(cmake|cmake-dist) case "$ci_variant" in (reduced) set -- "$@" -D ENABLE_SYSTEMD=OFF ... maybe more options here later ... ;; esac case "$ci_host" in (*-w64-mingw32) ... back to the current code ...
mirroring the way it's done for Autotools, then that would be fine.
The simple way to resolve this would be to drop this commit, and consider adding
ci_variant
as a separate MR.