bug-libtool
[Top][All Lists]
Advanced

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

portability requirements for libtool (was: cwrapper generates long strin


From: Ralf Wildenhues
Subject: portability requirements for libtool (was: cwrapper generates long strings.)
Date: Sat, 2 Oct 2010 11:37:19 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

* Ingo Krabbe wrote on Sat, Oct 02, 2010 at 11:06:46AM CEST:
> On Sat, Oct 02, 2010 at 08:32:24AM +0200, Ralf Wildenhues wrote:
> > > +       $SED -n -e '
> > > +s/^\(.\{79\}\)\(..*\)/\1\n\2/
> > 
> > \n is portable only in the regex part, but not in the replacement part.
> > For that you need backslash then literal newline.
> > 
> 
> This answer contains a part of my most burning questions about libtool
> development:
> 
>       A- what system tools are allowed to assume portability
>               (sed,tr,ed, ...)

The GNU Coding Standards lists the set of allowed tools.
Posix documents what *should* be portable, and the Autoconf manual
roughly documents (should document) most differences between that
and reality.

There are a couple more unofficial sites documenting portability issues.

>       B- what shell version to be assumed or which shell features might be
>               used.  Especially I think about `info bash
>               "basic shell features" "shell expansions" "shell
>               parameter expansion"`

Posix shell.  We do use XSI or bash features but only in code that is
ensured to not run when those features are not available.  It must be
sure that older shells do not fail, for example some older shells will
already fail parsing parameter substitutions like ${foo/bar/} even if
inside a 'if false; ...; fi' branch.

We've been doing quite a few optimizations that turn on better features
when they are available.  There are ways to go though.

>       C- what about writing parts as compiled programs? Some parsing
>               tasks could be done much faster and solid through real C
>               code or what about perl.

That will basically break all cross-compiled programs.  Requiring a
build compiler in addition to a host compiler is a major complication.


For nontrivial contributions, we need a copyright assignment.  Details
off-list if you're willing to contribute (takes a few weeks to
complete).

Thanks,
Ralf



reply via email to

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