On Fri, 8 Feb 2019 at 20:45 Matthew Woehlke <mwoehlke.floss_at_[hidden]>
wrote:

> 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?
>

Nope, tools will have to be adapted.
As long as it is possible and reasonable, it seems reasonable.
Without modification, ccache couldn't benefit from clang modules either


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.
>

Or send the sources, let the node duplicate BMI builds or a fine-tuned
balance of the too,
you can probably get some parallelization by doing duplicated work.



>
> --
> Matthew
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>