bug-libtool
[Top][All Lists]
Advanced

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

Re: [0/3] Different sed program could be used in libtool script


From: Ralf Wildenhues
Subject: Re: [0/3] Different sed program could be used in libtool script
Date: Wed, 10 Dec 2008 21:36:07 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Yann,

first off, thank you for the report and the patches.  Please
note that, in order to accept nontrivial patches, the FSF needs
a copyright assignment from you, more off-list.  Also please
send further patches to the libtool-patches list, thank you.

* Yann Droneaud wrote on Wed, Dec 10, 2008 at 05:30:14PM CET:
> Through out the libtool script, $SED is used, but sometimes 'sed' is
> used directly.
> 
> Libtool should be consistent regarding to which sed is used in the
> script.

This may sound like a dumb question, but is meant to be honest: why?

Autotools generally assume a mostly sane environment that has certain
unixy tools available.  Indirections like $SED cater to actual
limitations in existing (mostly proprietary) implementations, like line
length limits, bugs, or slow execution speed.  However, many uses of sed
in Libtool are not really relevant to these issues.

Remains bugs we don't know about yet, and maybe things like "why let
/bin/sed in the file cache when /opt/bin/gsed already is".  Maybe a
minor point but not all that relevant with today's systems.

Mind you, there are disadvantages of using $SED: you have to ensure
that each macro that executes $SED has require'd _LT_DECL_SED (you
seem to have taken care of this in the patches).  Each libtool
variable that contains $SED (quoted) needs to have the right escaping
done at config.status time.  Errors here do not happen often, but they
have happened, so there needs to be some actual advantage to making
the change.

Thanks,
Ralf




reply via email to

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