Re: path normalization

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Wed, Jan 19, 2005 at 02:10:46PM CET:
> Ralf Wildenhues wrote:
> > 
> > This is my first try at a shell function that implements this with
> > sed (and little overhead in most trivial cases).  I'm posting it
> > because it's not trivial, and I'd like to know about bugs in it or 
> > general comments on this problem (before integrating into Libtool)
> > or the choices I had to make about normalization, or possible
> > simplification.  The size of the script is partly due to the fact
> > that we cannot use alternation `\|'.
> 
> The implementation looks fine to me, and works on  Good work!
> 
> Tested with: ash-0.3.8, bash-2.05b, pdksh-5.2.14 and zsh-4.1.1,
> all using GNU sed 4.0.9.

I feared it'd rather be different seds that barf.  I did tests
with Solaris sed, AIX sed, GNU sed, and all shells I could find
on those systems.  The comment removal is a requirement for the
sed script.

> Here are some more ideas:
> 
> 1. We could avoid the normalization step on .la files that are new
>    enough by checking the version (or for speed adding a new
>    'pathsnormalized=yes' declaration) to decide whether it was already
>    done at creation time.

Maybe.  But don't let youself fool by my test cases -- if most
paths fit the "trivial case", it's not slow.  But see below.

Moreover, as soon as you concatenate paths, you have to redo the
normalization anyway, so in general you don't win very much.
(Think: cross-compilation.  Oh, BTW, just so that nobody ever
thinks of it: we will *NEVER* support cross-compilation on Windows.
I.e., where build=win, and host!=win.)

..time passes..

D*mn.  With a cross-compile build=linux, host=cygwin we might have to
deal with stuff like /tmp/stage/C:\usr\local\lib.  Puke.

> 2. Shipping a script to optionally trawl the filesystem and normalize
>    installed .la files (and add a pathsnormalized decl) at libtool 'make
>    install' time would save time for subsequent libtool calls.

Eww.  One bug in that script and you're doomed forever.  You can expect
users to have the sources of the package they just compiled and
installed, but not to all software on the system.

> 3. I wonder how much of the normalization we could do with M4 as the
>    libtool script is generated?

How?  m4 sees nothing of the paths, as they are potentially end-user input.

4. Change libtool m4 configury to look harder for a fast shell and for a
builtin $ECHO.  If we have ash, use it but with builtin printf and not
/bin/echo.

I did a little test with roughly 4000 entries of /usr/lib/*.
Without forks, bash is about a factor 20 slower.  Even with /bin/echo,
ash is much faster, and even with my test cases which all trigger the
sed, the speedup incurred by using ash over bash is noticeable.
I.e., it might make sense to look harder for a decent $SHELL/$ECHO
combination.

Regards,
Ralf