[PATCH] D25337: [Modules] Add a command line option for enabling the modules feature exclusively for the Clang builtins.

[Elad Cohen via cfe-commits]

eladcohen added a comment.

In https://reviews.llvm.org/D25337#571877, @rsmith wrote:

> I really don't like the command-line interface you're proposing here. It seems like it will be extremely confusing what something like `-fmodules -fexclusive-builtin-modules` means, for instance (usually, later `-f` flags override earlier ones, so does this *turn off* modules for everything other than builtin headers?). Instead, we should use a command-line interface that more naturally / obviously composes with other flags.
>
> It seems like the behavior you want here is precisely:
>
>   `-fmodules -fno-implicit-module-maps -fmodule-map-file=<resource dir>/include/module.modulemap`
>   
>
> (The `-fmodules-validate-system-headers` part would only make sense for people using clang directly from their build area; installed / released versions of clang should not need this. Adding it makes your flag compose poorly with other uses of modules.)
>
> I'd be happy with you adding a flag that is equivalent to `-fmodule-map-file=<resource dir>/include/module.modulemap`.


You are right, this is the behavior I was aiming at. I just hoped I could get a single flag to achieve it instead of 3, but I agree that it doesn't behave well with the other module flags.
I uploaded the new flag in a separate review: https://reviews.llvm.org/D25767

> Also, it seems unlikely to me that we would ever turn this on by default. It will cause havoc for distributed builds, especially ones that run compilation actions in 'clean' environments, as (for instance) it will cause the complete set of intrinsics headers to be compiled into a module on every compile. So if this is your proposed solution for slow compiles using intrinsics headers, you should be aware that this is not a complete solution to that problem.

What do you mean by 'clean' environments? As in no intermediate artifacts (such as the .pcm files) could be cached?

Do you have any thoughts or suggestions on how we can make the solution more complete?

I guess one possibility to handle this matter (IIRC mentioned by Chandler in one of the discussions) is to pre-compile the actual builtins module as part of the build system. But IIUC this is not feasible since there could be a huge matrix of all the different configurations we will have to maintain, right?


https://reviews.llvm.org/D25337