Re: Patch: RFA: new option

[Ralf Corsepius]

On Wed, 2003-08-06 at 06:49, Tom Tromey wrote:
> >>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
> 
> Tom> I'd like to get this in 1.7.7 so that we can start using it in gcc.
> 
> adl> So that will be a "bug fix++" release.  If this can push
> adl> newer Automakes in the gcc tree I presume it's a Good Thing.
> 
> Yeah, I think so.
> 
> Tom> We're also looking forward to the post-1.7.6 multilib bug fixes.
> 
> adl> I'm glad to hear that.  After Alexandre Oliva's comments [1]
> adl> I've been wondering whether fixing these rules was better than
> adl> removing them entirely.
> 
> Well, I was using the royal "we", meaning me.  It will simplify a few
> Makefile.ams in the gcc tree.
> 
> If gcc gets rid of config-ml.in and moves multilibs to the top level,
> that will be nice all around.
Could you elaborate? 

Besides of this being an opportunity to get rid of some of
config-ml.in's "gross" internals, I don't understand why that would be
advantageous. 

In contrary, AFAIU this would probably merge config-ml.in's internal
details (esp. the "filtering multilib exceptions") into the (AFAIU,
toplevel) configure script.

I also don't see that "toplevel-ing" multilibs helps wrt. other
deficiencies the current multilib-support implementation has (esp. with
deep subdirs in general and header installation).

>   The reason I pushed multilib code into
> automake was to avoid having config-ml.in (or was it user configure.in
> scripts?) add dependencies in an unsafe way.  Building them from the
> top level will mean we can just remove all the gross code.
> 
> Having support for multilibs in a non-gcc tree is a different thing.
> It never occurred to me that somebody would want that.
We (RTEMS) are using multilibs w/ automake.

They currently are implemented by using customized versions of
automake-1.7.x's multi.m4 and multilib.am + a customized gcc-3.4
config-ml.in, because the versions shipped with automake up to now do
not suite to our needs and because we were hoping that multilib support
in automake once upon a day would reach a "usable" status (it currently
isn't.)

I.e. if you want to remove multilibs from automake, this probably will
not desturb us. However, I continue to think multilibs should be
improved, be generalized and be implemented in automake.

Ralf