Re: -recursive

[Ralf Corsepius]

On Mon, 2003-07-07 at 01:59, Alexandre Duret-Lutz wrote:
> >>> "Akim" == Akim Demaille <address@hidden> writes:
> 
> [...]
> 

> 
>  Akim> But there is not much information in there :(
> 
> Oh, if there is no test case it probably isn't important... <wink>

... cf. the attachment below ...

Well, multilib support in automake is "so-broken-it-hurts (TM)" ;-)

Actually, all projects supporting multilibs I am aware about, either
work around these bugs by applying package specific macros and Makefile
fragments instead of using automake's or use autoconf alone..

(Furthermore, config-ml.in is victim of an autoconf-2.5x/2.13
ac_configure_args quoting incompatibility
cf.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11526
which prevents using multilibs with automake-2.5x in general.)

Anyway, below is a test case triggering some of the nastinesses lurking
in autoconf/automake and config-ml.in.

The tarball contains a hacked config-ml.in (from gcc-3.4) and uses
automake generated files, generated by an automake-1.7.x having applied
the patch I had sent to automake-patches earlier today)

Note: The tarball only works with VPATH builds (in-source-tree builds
with multilibs also don't work.)

> (I'm not familiar with the multilib stuff though.)
... and I don't understand what you are doing with the recursive make
targets in automake ... :(

Ralf

automake-multilib-0.1.tar.gz
Description: GNU Zip compressed data