iains added a comment. In D137058#3906579 <https://reviews.llvm.org/D137058#3906579>, @dblaikie wrote:
> I realize I got this jumbled up and the thread about "why do we need to name > things" is meant to be over in D137059 <https://reviews.llvm.org/D137059> > (sorry @ben.boeckel :/ I know this is all confusing to follow at the best of > times) so I'll pick that up there. > > But maybe a relevant question /here/ (maybe @iains has some context here, and > @ben.boeckel ): What are GCC's (& any other implementations) command line > interfaces for things like this? How're the command line flags spelled? To > see about inspiration for this. .. the state I have is ... As you note there are two parts to this: 1. the ability to emit a BMI and object from one invocation of the compiler (which can be done as in this series by the driver - or with alternate patches in the FE - which allows for the improvements we want in the BMI) 2, How to name the BMI. - in my experimentation with GCC, for this part, it defers the decision until the module name is known, and then queries an interface to ask for the BMI filename for that named module. The interface can be internal (e.g. choosing a simple default like source.pcm) or it could get the mapping from some other place, like a build system. The FE side of the transaction does not need to know how the name was chosen (so it _could_ be specified from a command-line flag). - but, AFAIR, GCC does not currently have such a flag. > (judging from the discourse thread with @rsmith it seems like "the ability to > generate a .o from a .pcm" is disfavored, he didn't outright say "we should > remove that functionality" but pretty close to it - in favor of ".cppm -> > {.o, .pcm}" and ".ccpm -> .o" + ".cppm -> .pcm" (without the ability to > generate the .o from the .pcm) - in which case we could change the existing > driver behavior sooner or later to address that third action (.cppm -> .pcm > but it's only a minimal pcm). This is the strategy my draft patches for the FE aims for (apologies, for repeatedly mentioning a patch set that is not yet up for review ...) Maybe we should have two flags one that says "produce a .pcm" (which we already have `--precompile` for that) and another that says "produce a .o" (I guess that's the default, so maybe we want a way to opt /out/ of that behavior?)) > Eh, sorry, just talking myself around in circles. > Currently we have: > `.cppm` -> `.o` (no extra flags) > `.cppm` -> `.pcm` (`--precompile`) > `.cppm` -> `.pcm` + `.o` (unsupported) > > I'm not sure that `--precompile` is the best flag name to be inspired by > (it's unqualified by any `-f` or other prefix, which usually feels a bit > weird, and it's a very generic term, doesn't mention modules, etc) - GCC has "-fmodule-only" for which I have a patch (also unpublished) that aliases that to --precompile in the driver. (I think we could possibly see a reason to have -fobject-only for symmetry and to cover the cases you mention here) > so I can appreciate the `-fsave-std-c++-module-file` name here, but it does > sound a bit verbose? Wouldn't mind hearing other people's thoughts on flag > names, especially any prior art/other implementation choices we could look > for for inspiration. What was the objection to "-fc++-module-filename[=]" ? As noted above, if my memory is not too faulty, GCC does not have this specific [name the BMI] flag yet (I think this is the case because GCC essentially uses a simple in-process P1184 <https://reviews.llvm.org/P1184> interface as the fallback when there's no external build system), then this flag name is up for grabs - and what is chosen here could, presumably, be implemented for GCC too. Actually, in some ways clang does something pretty similar in that there's the in-process module-mapper - which is where the filenames probably should be decided, we just tend to bypass it with specific command line input for output filenames (which does not work where there are two names needed, except by providing some simplified fallback - like the "just change the extension" approach). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137058/new/ https://reviews.llvm.org/D137058 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
