dblaikie added a comment. In D57976#1393976 <https://reviews.llvm.org/D57976#1393976>, @aprantl wrote:
> In D57976#1393939 <https://reviews.llvm.org/D57976#1393939>, @dblaikie wrote: > > > This, I guess, is part of the impact of moving towards explicit modules > > (-fmodule-name is for building a module with that name, right?)? > > > That option is overloaded. It's used to specify the name of an explicit > modules too, but in this context particularly it is used to specify that > clang is compiling the Framework that defines the module with that name, > which has the effect of *not* building the module of that name as a clang > module even though -fmodules was specified and every other module is built as > a module. This is necessary for developing Frameworks that are part of the > macOS SDK to avoid accidentally include the module from the OS instead of the > one being developed. That's a quite specific use-case. > > > With explicit modules there is the option for modular code generation - > > which doesn't require any specific DWARF consumer support (so should "just > > work" - if you've a build system you can teach to generate a .o file from > > the .pcm, and link that .o with everything else) > > Different can of worms, I believe. Ah, fair enough - thanks for the context! Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57976/new/ https://reviews.llvm.org/D57976 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
