Filed as issue #1183.
Sander
On Mon, Mar 03, 2003 at 05:45:38PM +0100, Marcus Comstedt wrote:
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 11 14:57:33 2003