build regression

[Tom Tromey]

>>>>> "Neil" == Neil Booth <neil@daikokuya.co.uk> writes:

Alexandre> I mean...  If we (ok, you :-) are revamping the
Alexandre> command-line option handling, wouldn't we be better off
Alexandre> with a system that doesn't require all languages (even
Alexandre> those outside our tree) to agree on whether an option takes
Alexandre> arguments or not?

Neil> I disagree.  You might have a point if there were, say, one or two
Neil> dozen switches where this was the case.  However, it appears that
Neil> there are just these two, and the difference is not even user-visible.
Neil> It's not a maintenance problem either.

I think from a UI point of view, Neil's approach is sound, especially
as long as we can invoke "gcc -x language ..." to invoke non-C
compilers.  In this situation uniformity seems important.

However, it does imply that we need some central clearinghouse for
adding new options.  This is a change from the past.

For gcj our hope has been that we could have "gcj -C" be a drop-in
replacement for "javac".  This means having option compatibility.
I wonder if this goal is still possible to achieve.

Tom