On Dec  9, 2019, Richard Biener <rguent...@suse.de> wrote:

> On Tue, 3 Dec 2019, Alexandre Oliva wrote:

>> I'm considering rejecting command lines that specify both an explicit
>> -dumpdir and -save-temps=cwd, and in the absence of an explicit
>> -dumpdir, arranging for -save-temps=cwd or -save-temps=obj to override
>> what would otherwise be the default -dumpdir.

> Making -save-temps=cwd essentially a short-cut to -save-temps -dumpdir ./
> is fine I guess (we usually do not start to reject previously accepted
> options).

What if -save-temps=* and -dumpdir both set the same underlying aux
output dir, with the latest one in the command line prevailing, rather
than being rejected?

>> gcc -c foo.c -dumpbase foobar && gcc -c bar.c -dumpbase foobar
>> 
>> and
>> 
>> gcc -c foo.c bar.c -dumpbase foobar
>> 
>> The latter will name outputs after foobar-foo and foobar-bar,
>> respectively, whereas the former will overwrite outputs named foobar
>> when compiling bar.c.  Under the proposal to modify %b according to
>> -dump*, even object files would be named after an explicit -dumpbase,
>> when -o is not explicitly specified.

> I think rejecting option combinations that do not make much sense
> or would introduce inconsistencies like this is better than trying
> to invent creative things second-guessing what the user meant.

Hmm, I sense conflicting recommendations here vs the previous block ;-)
A single -dumpbase when compiling multiple sources used to be accepted,
after all, it just overrode aux outputs so only the last one prevailed.


> Hum.  I didn't notice -dumpdir is just a prefix and I wouldn't object
> to make it errorneous if it doesn't specify an acutal directory.

But would you object to retaining the ability to use it as a prefix?

> I also note that neither -dumpdir nor -dumpbase are documented
> in invoke.texi

*nod*

> Not sure if all this means we should document the altered behavior
> or if we should take it as a hint we can alter behavior at will
> (in future) ;)

I suppose we have more leeway in changing what's not even documented.


Thanks again for the feedback!

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist           Stallman was right, but he's left :(
GNU Toolchain Engineer    FSMatrix: It was he who freed the first of us
FSF & FSFLA board member                The Savior shall return (true);

Reply via email to