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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
