Well, since I seem to be on a roll with getting patches committed, I
might as well go for broke... :-)
This is the only remaining non-committed patch that I need to build
Subversion on my machine. The problem is that autogen.sh makes
assumptions about being able to construct the path of libtool.m4 from
the path of libtoolize that don't hold. libtool is installed with its
own prefix, and the "libtool" and "libtoolize" which are in the path
are symlinks into this directory. Note that this does _not_ prevent
libtool/libtoolize itself from working in any way. The problem is
local to Subversion (and APR, which does the same thing, but that's
for a different mailing list I suppose).
I have two suggestions for fixes. Neither is particularly pretty.
But neither is the original code. At least these work...
The first version extracts the relevant variable bindings from the
libtoolize script in order to get at the variable $libtool_m4, which
points out the correct location of libtool.m4. Potential problems:
Will only work as long as the libtoolize script contains a variable
with this name with this value. Can also break if multi-line variable
bindings are added to the libtoolize script.
The second version instead actually runs libtoolize (in dry-run mode)
since this prints the path name of libtool.m4 on stdout. This way
there is no dependency on the internal structure of the libtoolize
script, but instead we get a dependency on the formatting of the
output from the script. Personally, I still like this version better.
If somebody can think of a method to do this correctly _and_
beatifully, please speak up. :-) Ideally, libtoolize should of
course have a flag that makes it just print the path to libtool.m4 and
exit, but currently it doesn't.
Ok, don your dark glasses, horrible /bin/sh code coming up... :-)
Patch variant 1: Extract variable bindings from libtoolize
Index: autogen.sh
===================================================================
--- autogen.sh (revision 5189)
+++ autogen.sh (working copy)
@@ -50,8 +50,7 @@
$libtoolize --copy --automake
-ltpath="`dirname $libtoolize`"
-ltfile="`cd $ltpath/../share/aclocal ; pwd`"/libtool.m4
+ltfile="`(sed -e '/^libtool_m4=/q' -e '/^[_a-z0-9]*=/!d' <$libtoolize;echo 'echo \"$libtool_m4\"')|/bin/sh`"
if [ ! -f $ltfile ]; then
echo "$ltfile not found"
Patch variant 2: Extract path from output of libtoolize -n:
Index: autogen.sh
===================================================================
--- autogen.sh (revision 5189)
+++ autogen.sh (working copy)
@@ -50,8 +50,7 @@
$libtoolize --copy --automake
-ltpath="`dirname $libtoolize`"
-ltfile="`cd $ltpath/../share/aclocal ; pwd`"/libtool.m4
+ltfile="`$libtoolize -n -f 2>/dev/null | sed -ne 's/^.*the contents of \`'\"\\([^']*\\)'\"'.*$/\\1/p;q'`"
if [ ! -f $ltfile ]; then
echo "$ltfile not found"
I have tested both variants and they worked for me, but I can't
guarantee that they will work with every future version of libtool of
course.
A third variant that doesn't involve so much dependencies on
libtoolize itself would be to keep the original method and just try to
resolv all symlinks in the path to the binary. This is a bit tricky
to do portably though, and there would still be a dependency on the
installed directory structure of libtool (which may change just as
well as the contents of the libtoolize script). So basically I think
that would just be more code, not necessarily more robust. Also, such
a solution would not work in the (admittedly rare) case where the
binaries are hardlinked to a different location instead.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 3 17:49:17 2003