maria-developers team mailing list archive

[Otto Kekäläinen <otto@xxxxxxxxx>]

2014-12-24 14:34 GMT+02:00 Sergei Golubchik <serg@xxxxxxxxxxx>:
> Try CC=gcc CXX=g++ before running cmake.
>
> I don't know exactly in what locations cmake is using for a compiler and
> why it doesn't pick up your symlinks automatically.

Ok, I managed to figure it out now. The solution was to create this two
symbolic links:

ll /usr/local/bin/x86_64-linux-gnu-g*
lrwxrwxrwx 1 root root 15 joulu 27 17:01
/usr/local/bin/x86_64-linux-gnu-g++ -> /usr/bin/ccache*
lrwxrwxrwx 1 root root 15 joulu 27 17:02
/usr/local/bin/x86_64-linux-gnu-gcc -> /usr/bin/ccache*

The problem was in two parts: First I thought that the cacheable commands
was cc1 and cc1plus, since that are the names of the binaries where the
build process spends most of its time. Turns out those cannot be handled by
ccache. Instead I needed to wrap the step above them and that meant the
invocation of gcc via the name x86_64-linux-gnu-g*. Second issue was that
the git-buildpackage fakeroot didn't inherit the PATH of the parent
environment, so I instead of manipulating the PATH I simply added the
symbolic links to a location where they are read and triggered before
/usr/bin, and /usr/local/bin was such a place.

The time saving is huge. My full git-buildpackage run went down from 25-33
minutes to about 4 minutes. The size of the cache is less than 0,5 gigs, so
I could maybe make it even more faster by placing the cache on a ramdisk:

$ ccache -s
cache directory /var/cache/ccache
[..]
files in cache 3325
cache size 426.3 Mbytes
max cache size 2.0 Gbytes

By the way, why does not the buildbot infrastructure use ccache? It could
have a common nfs mounted /var/ccache directory that all the builds share
that could presists from build-to-build? Most of the commits just touch a
few files so ccache would be able to save lots of compilation time as only
the changed files would be compiled.