[PATCH] D137058: [Driver] [Modules] Support -fmodule-output (1/2)

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.


================
Comment at: clang/lib/Driver/Driver.cpp:5736
+      C.getArgs().hasArg(options::OPT_fmodule_output) &&
+      C.getArgs().hasArg(options::OPT_o)) {
+    SmallString<128> OutputPath;
----------------
dblaikie wrote:
> ChuanqiXu wrote:
> > dblaikie wrote:
> > > Is there some way we can avoid this (`-fmodule-output  -o ...`) being a special case? It'd be good if we could use a single common implementation regardless of whether `-o` is used (ie: Figure out the output file name (whether it's implicitly determined by clang, in the absence of `-o`, or explicitly provided by the user through `-o`) and then replace the suffix with `pcm`)?
> > I guess we can't do it or we can't do it easily. Otherwise the .pcm file will always lives in the same directory with the input file.
> > I guess we can't do it or we can't do it easily. Otherwise the .pcm file will always lives in the same directory with the input file.
> 
> I don't follow/understand. What I mean is, I'd like it, if possible, this was implemented by something like "find the path for the .o file output, then replace the extension with .pcm".
> 
> I worry atht code like this that recomputes something similar to the object output path risks getting out of sync with the actual object path.
That is certainly a valid concern and I agree it would be better if the shared output path is computed exactly once. If that would require significant change, then tests to ensure consistent behavior would be the next best thing. I'm not sure what infrastructure is in place for validation of output file locations though.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137058/new/

https://reviews.llvm.org/D137058