[Top][All Lists]
[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.