On Thu, Mar 26, 2020 at 02:50:48PM +0100, Andrea Bolognani wrote:
> On Thu, 2020-03-26 at 12:35 +0000, Daniel P. Berrangé wrote:
> > For any given job there is a high liklihood that ccache will be able to
>
> *likelihood
>
> [...]
> > .native_build_default_job_template: &native_build_default_job_definition
> > stage: native_build
> > + cache:
> > + paths:
> > + - ccache/
> > + key: "$CI_JOB_NAME"
> > + before_script:
> > + - mkdir -p ccache
> > + - export CC="ccache gcc"
> > + - export CCACHE_BASEDIR=${PWD}
> > + - export CCACHE_DIR=${PWD}/ccache
>
> Having to set this up at the job level is kinda gross, and
> specifically the
>
> export CC="ccache gcc"
>
> trick is 1) not going to work for FreeBSD and 2) going to break
> Go builds.
That's easy enough to fix for FreeBSD - we just set CC=clang vs CC=gcc
variable for the jobs at the top level, and then this code can change
to CC="ccache $CC".
We don't have any Go code in libvirt but what's the issue with ccache
in that case ?
> Ultimately I think we need to take a cue from what lcitool does when
> configuring VMs and generate a simple environment file that is baked
> into images and can be sourced from jobs with a single line.
I much prefer to have the job configuration all in the gitlab config file
rather than split between the gitlab config and the images, as it lets you
understand the full setup.
We could however make the container images setup a link farm for ccache
as we did with the VM images. So then the job just needs to set the
$PATH to point to the link farm bin dir, instead of $CC.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
