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);