On 2/8/19 12:26 PM, Mathias Stearn wrote:
>
>
> On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> I've been recently claiming two properties of Clang Modules that I
> believe have been central to their success.
>
> 1. Clang modules are built on #include directives in such a way
> that existing tools that have no knowledge of Clang modules
> continue to work as they always have.
> 2. Modules are built implicitly on demand (by default) such that
> build system updates are not required (other than to pass
> '-fmodules' to enable the feature).
>
>
> Unfortunately that design of "compiler handles everything, build
> systems are oblivious" means that clang modules break several
> important build-system-adjacent tools, such as ccache[1] and
> icecream[2]. distcc is likely also affected since it originally worked
> the same as icecream. It is possible that the new "pump" mode makes it
> work in distcc, but I don't have a cluster to test that on.
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 think the clang modules design makes it somewhere between hard and
> impossible for these kinds of tools to work well with them. Support
> for distributed builds is one of my major concerns with modules.
> Almost any form of modules that isn't just "better scoping in headers
> with no caching" will make distributed builds more complicated than
> today. I want to hope that this problem is solvable though. Having the
> machinery hidden in the compiler rather than explicitly managed makes
> it substantially harder (while admittedly making simple builds simpler).

Given that Clang does have options to allow explicit control of module
artifacts when desired, does that help to address your concerns here?
E.g., use explicit module artifact management only when beneficial.

Tom.

>
> [1]
> https://github.com/ccache/ccache/blob/2753dafa38e14bfc5d4bb5c2b692edad964aaef6/src/compopt.c#L66
> [2] This is how I tested. It also fails with remote cpp enabled. If
> there is a better way, I'd be happy to try it.
> > ICECC_REMOTE_CPP=0 ICECC_PREFERRED_HOST=remote_host
> /usr/lib/icecream/bin/icecc clang++ -fmodules -c test.cpp
> test.cpp:1:29: fatal error: module 'Header' not found
> #pragma clang module import Header /* clang -E: implicit import for
> #include "header.h" */
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling