On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote: > Out of the Linux distros we build on in the CI, clang > is only available on Fedora. Uh? I guess you based this claim on https://repology.org/project/clang/versions but the information contained in that page is inaccurate: clang is actually also available on CentOS 7 3.4.2 (via EPEL) CentOS 8 9.0.1 Debian 10 7.0.1 Debian sid 10.0.1 openSUSE 15.1 7.0.1 Ubuntu 18.04 10.0.0 Ubuntu 20.04 10.0.0 Some of those versions might be too old to be useful, but claiming that clang is only available in Fedora is simply inaccurate. > Add a job to Fedora 31 and Rawhide, to have coverage > for clang on Linux as well. I get Rawhide, but why Fedora 31 instead of 32? The former is going to be EOL in a few months. Also, based on the above, do you think we should have clang builds on more platforms or are two Fedora builds giving us enough coverage? > Includes a refresh of the Dockerfiles to commit TBD: > https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/38 I would prefer the Dockerfile update to be its own commit. > +++ b/.gitlab-ci.yml > @@ -52,7 +52,7 @@ stages: > script: > - mkdir build > - cd build > - - ../autogen.sh || (cat config.log && exit 1) > + - ../autogen.sh CC=$CC || (cat config.log && exit 1) Have you tried without this hunk? $CC is already defined in the container's environment and I would expect autogen.sh/configure to pick the value up, so I *think* it should work even without passing it explicitly... > +x64-fedora-31-clang: > + <<: *native_build_job_definition > + needs: ["x64-fedora-31-container"] We haven't introduced this pattern yet, so please stick with the current approach for the moment and then switch these jobs over along with all the other ones in the follow-up commit. > + variables: > + CC: clang > + NAME: fedora-31 Bikeshedding: I'd put NAME first. -- Andrea Bolognani / Red Hat / Virtualization
