dblaikie added a comment. In D134267#3869643 <https://reviews.llvm.org/D134267#3869643>, @iains wrote:
> In D134267#3869614 <https://reviews.llvm.org/D134267#3869614>, @dblaikie > wrote: > >> In D134267#3869162 <https://reviews.llvm.org/D134267#3869162>, @iains wrote: >> >>> In D134267#3868830 <https://reviews.llvm.org/D134267#3868830>, @dblaikie >>> wrote: >>> >>>> I'm OK with sticking with the existing `-fmodule-file` if that works for >>>> everyone. Yeah, it's short and ambiguous in a space with many concepts of >>>> what a "module file" is, but also the fact that it's a `-f` flag might >>>> help disambiguate it a bit - it's probably not the way anyone would >>>> think/expect to be passing source files, those just get passed without >>>> flags on the command line. And any use of it will show the .pcm extension >>>> or whatever that should make it clear enough what's going on. >>> >>> hmm (I realise I mentioned this, and hope it has not complicated things) .. >>> >>> .. I was thinking of the `-fmodule-file=<name>=filename` variant. The >>> problem with using it without (the <name>) is that -fmodule-file= can (and >>> does) appear multiple times on the command line to specify dependent >>> modules - so that one would have to specify which (named) module was >>> related to the filename. > > > >> I /think/ currently `-fmodule-file` works with Clang header modules >> presumably because the module files contain within them enough information >> to enable the compiler to substitute the module for an include where >> necessary? I'm not sure the `<name>=` part is necessary, as such, if the >> BMIs can reasonably contain enough identifying info to make their use clear >> to the consumer. > > `-fmodule-file=` works with both `clang` modules and standard C++ ones. > What it does (as of now) is cause the FE to open the named file and to > pre-load the module name - so that when the FE tries to find a module the > lookup mechanism can associate the module name with the module data. So, if > we need 3 dependent modules to be available when building a new source .. we > would specify the PCM files containing those modules. > > At present, if you try to specify a non-existent PCM using `-fmodule-file=` > the compile will fail early on (it is expecting this to indicate a source > module, not a destination one). > > However, the second syntax `-fmodule-file=<name>=filename` I think should be > able to work around this (since it says that the named module <name> is > associated with the PCM `filename` which would allow us to cater for that > file being missing (when we are creating it). Would the intent be that this might write out multiple different module files? I would hope we don't need to support that - that we only generate the module file for the single source module passed to the compiler. I guess maybe to support `clang++ x.cppm y.cppm` you might have multiple output files? But in that case you don't get to use `-o` so maybe you don't get to specify the module paths either and just get the default "same as .o but with .pcm suffix" behavior? > Does that clarify at all ? > > It would be great not to add more modules options flags, there are already > way to many :/ - but if this seems too complex then one of the spellings > suggested by @ChuanqiXu would work. Oh, right, super sorry - this is about how to specify the output filename. OK. (I'd still sort of lean towards "make it the same as the .o, but with the .pcm suffix" and if the build system wants to put things in other places, it can move them around - but I understand why that's not something everyone's on board with) Yeah, if the `-fmodule-file` syntax is currently only for input I don't think we need to try to overload it for output as well. Perhaps we could extend the --precompile flag to take a filename? (but then that'd potentially confuse things when you want to produce both PCM and .o, passing `--precompile` currently only produces the .pcm on the main output path... ). Anyone got a list of other compiler flags that take output file names? (I guess profile generation, maybe some other flags do this? Might be worth comparing/contrasting/seeking inspiration from those? I guess `-save-temps` uses the "same path, different suffix" strategy) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134267/new/ https://reviews.llvm.org/D134267 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
