On a Wednesday in 2020, Andrea Bolognani wrote:
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
Yes.
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.
Any Fedora release is, by definition, 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?
The intention was to use different versions of the compiler.
If running it on the oldest still-supported Fedora interferes with
your passion in purging releases that don't let us drop any code,
I can replace it with a combination of:
rawhide + centos 8 + debian 10
or
rawhide + centos 8 + opensuse 15.1
(And thanks for pointing that out, my Gentoo box still defaults to
clang7)
> 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.
Yes.
> +++ 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?
No.
$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.
/---\ Speaking of which, do you have a better suggestion for the job
| | name? 'x86-fedora-rawh' is all that fits into the bubble on
| , | the pipeline website. Almost as if it was designed for CI,
| o-o | not CUT.
Jano