GitLab

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, the production (default), debug, reduced and legacy 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 into debug, and we bundle a lot of optional features being disabled into reduced.

  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.