This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, toplevel] --enable-multilib*S* is an easy typo to recognize...

On Sun, Feb 15, 2004 at 05:22:43PM -0500, Phil Edwards wrote:
> On Sun, Feb 15, 2004 at 06:25:12PM -0300, Alexandre Oliva wrote:
> > On Feb 15, 2004, Phil Edwards <phil@codesourcery.com> wrote:
> > 
> > > On Sun, Feb 15, 2004 at 02:37:36AM -0300, Alexandre Oliva wrote:
> > >> Consider that we drop into the top level a new package that takes
> > >> --enable-multilibs as an argument?
> > 
> > > Ew.  I would hope we would point to gcc's spelling and say, conform or die.
> > 
> > Why should an unrelated package conform to GCC's spelling?
> 
> Because it's going in our tree?
> 
> > It doesn't even have to be *our* top level.
> 
> Huh?  Our top level is the one under discussion.  I'm not patching top level
> directories anywhere else.
> 
> 
> Enh, never mind.  I'll leave it in my local tree.

For the record, I'm with Phil on this one.  I think an error would be
entirely appropriate.  If, someday, we encounter a package that wants
the alternate spelling and have reason to integrate it, then we can do
something about it at the time.

Bear in mind that accepting unrecognized arguments isn't all it takes
to have multiple packages in the same toplevel configure.  What if they
have different - or conflicting - ideas of multilibs, for instance?  I
don't think we can draw conclusions without a case.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]