Speedup of packages build in Docker with ccache

[leugenea]

Description of Problem, Request, or Question

It might be helpful to allow using of ccache when building packages (if package support it, of course, in some way) inside Docker container to speedup rebuilds.

I'll try to illustrate it with simple workflow:

1. we're building package A with version 1.0.0 with some set of sources,
2. we're using it in release builds,
3. some bug is found in A,
4. we fix sources of A and create version 1.0.1 with almost same sources (let's assume that only a few .cpp files were modified),
5. we have to fully rebuild all packages.

So, maybe at step 5 we could use ccache to rebuild only a few .cpp file that were modified. For libraries with hundreds of source files this really could make a difference.

[danimtb]

I know there are users that are taking benefit from the ccache but not sure if they are using conan package tools. Maybe @joaquin-herrero could give us a hint here

[uilianries]

CPT uses Conan create to build any package, so the build_folder is discarded when a new build starts. I can't see an easy integration with ccache

[leugenea]

@uilianries, we could mount ccache cache location (could be set via CCACHE_DIR env variable for example, see docs) to Docker container (just like we mount source root) and reuse it between builds.

[uilianries]

I'm reading ccache docs, and for Conan Package Tools it's not a problem I think. You only need to set CC=<ccache_folder>/gcc and you are good to go. IF you are not using docker.

Conan Docker Tools is only about Docker images, so we need to install ccache for every Docker image and change the compiler paths to ccache link, but is a problem because we need know about any side-effect.

Also, re-using cache folder between builds is not a good practice. We saw some issues from users in the past.

[leugenea]

I'm not suggesting to re-use Conan cache folder between builds, I'm suggesting to re-use ccache cache.

It's not a big deal for me to install ccache inside all Docker images as we use our custom images. It's also not a problem to set correct environment vars to tell build system to use ccache.

The problem is that CPT doesn't allow me to mount ccache cache directory from host machine. Without this ability using of ccache is absolutely pointless.

[uilianries]

If you only want to add an extra volume, you can pass it by Docker options:

https://github.com/conan-io/conan-package-tools#passing-additional-docker-parameters-during-build

Also, if you need an extra some extra step when running your docker container, you can set an entry script

https://github.com/conan-io/conan-package-tools/#running-scripts-and-executing-commands-before-to-build-on-docker

[leugenea]

Oh… you're absolutely right! Looks like I've missed it.

But, returning to the question, it would be nice if CPT provided this as an option for multipackager.

About the safety of this solution. I've done some quick research about it, and looks like ccache can calculate hash of compiler binary (compiler_check parameter set to content), so there couldn't be any collisions between different OS's/compilers/etc.

[uilianries]

But, returning to the question, it would be nice if CPT provided this as an option for multipackager.

What do you mean? Passing a new volume is not enough for ccache usage?

[leugenea]

Of course it's enough, but I'm talking about native and simple integration.

My point is that CPT provides a lot of customization points like used Docker container, entry script, etc. It could be handy if MultiPackager class provided argument like docker_image, but for ccache. Something like ccache_data_dir.

[uilianries]

Okay, but only the directory path is enough? What about env var? As your original question requires Docker, we would need to create a docker container and inject a bunch of env vars, but I have no idea about those variables, even reading the docs.

[leugenea]

As far as I can see, mounting host cache directory and setting env variables CCACHE_DIR (to the mounted dir) and CCACHE_COMPILERCHECK (to content) should be enough.