On 08/02/2019 13.46, Tom Honermann wrote:
> I'd like to understand more why ccache is impacted. I don't have
> experience with the other tools, so can't comment on them.

I assume, because the preprocessed output is no longer self-contained.

The way ccache works is it *always* runs the preprocessor, then checks
if the result of doing so generates an input that has been compiled
previously. If so, rather than actually compile the TU again, it just
takes the artifact that was generated last time. (Obviously, build flags
are also part of the hashing.)

Once you have modules, this is no longer the case. At best, ccache has
to be able to find the modules that would be imported and hash them also.

For ccache, this seems feasible, though it means ccache needs to be
module-aware.

@Corentin, are you suggesting that modules as proposed would be easier
for ccache to implement than clang modules?

I *believe* the problem for distributed builds (caveat: I have no
experience here) is similar; currently, the 'master' system runs the
preprocessor and sends the result off to the 'slaves' to be compiled. In
this case, however, it would also need to send all the modules. Again,
*probably* not intractable, but getting a bit more difficult. OTOH, I
could imagine a setup where the 'master' just does dependency scanning
and packs up all the dependencies and sends that off. The 'slave' would
need to understand to use this "bundle" rather than the local file
system to find dependencies, but this would also allow some of the
preprocessing to be offloaded.

-- 
Matthew