automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling other external Makefiles and outside Make systems


From: Ralf Wildenhues
Subject: Re: Calling other external Makefiles and outside Make systems
Date: Tue, 27 Jan 2004 00:28:21 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

* Bob Friesenhahn wrote on Tue, Jan 27, 2004 at 12:03:56AM CET:
> On Mon, 26 Jan 2004, Ralf Wildenhues wrote:
> >
> > Oh, yes, you're right.  braino, sorry.  This one is not about
> > not changing the subpackage, but about saving space in the combined
> > package.  After all, auxiliary scripts with the same name are supposed
> > to be identical, right?
> 
> That would be a very poor assumption.  Scripts with the same name may
> output different values.  For example, an older config.guess script
> may output a different host tripplet for the same OS than a newer
> config.guess, and the version of tools used in the subdirectory key
> off this older host tripplet.  They would misbehave if they were
> directed to use the newer config.guess.

Ahh, thanks.  Well that surely destroys this idea.

But begs for another, config.guess related question:
Its output being this unstable means:  If you want to
make good use of config.guess, you better be tracking it
constantly.  Ok, I knew this method would be useful to
but a few packages (most notably libtool[1]), but this
is a strong reassurance.

Are there auxiliary scripts other than config.{sub,guess}
which expose complexity rather than hiding it?  Which?

BTW: Thanks for your comments, they really remove some
(unjustified?) expectations a user could get, only
half-understanding the way the autotools work internally.

Regards,
Ralf

[1] libtoolized packages as well, of course, but as long
    as that is the only use, the complexity is hidden in
    the libtool <-> config.* interface.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]