bug-gnulib
[Top][All Lists]
Advanced

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

Re: Failing to use gnulib bootstrap in libtool


From: Gary V. Vaughan
Subject: Re: Failing to use gnulib bootstrap in libtool
Date: Fri, 3 Sep 2010 03:15:44 +0700

And theres more...

On 2 Sep 2010, at 23:36, Gary V. Vaughan wrote:
> Is gnulib bootstrap designed for reuse in other projects?
> 
> I'm finding it extremely difficult to understand a lot of the code, let alone 
> incorporate it into Libtool.  I have some fixes for the obvious bugs, and a 
> lot of questions about the design choices, below.  In short, it could use a 
> complete rewrite.  I'd be happy to do the work, as long as I can be 
> reasonably confident that it will be accepted upstream, and that the more 
> obtuse parts of the incumbent script are explained to me.
> 
> These are the issues I've found so far:
> 
> 
> 1. gnulib_mk
> ============
> 
> [[...]]

I've noticed that I can almost get the vanilla gnulib `bootstrap' to succeed if 
I patch the obvious bugs, create a `.gitmodules' file and set `gnulib_mk' to 
`Makefile.am'... although with a more mature `bootstrap', none of those should 
be required!


13. gnulib_extrafiles
=====================

> build_aux=build-aux
> 
> [[...]]
> 
> # Extra files from gnulib, which override files from other sources.
> gnulib_extra_files="
>         $build_aux/install-sh
>         $build_aux/missing
>         $build_aux/mdate-sh
>         $build_aux/texinfo.tex
>         $build_aux/depcomp
>         $build_aux/config.guess
>         $build_aux/config.sub
>         doc/INSTALL
> "

$build_aux is interpolated by the shell with the `bootstrap' hard-coded value 
before `bootstrap.conf' has been given a chance to override it.  It would be 
better to do the substitutions later, either by shell escaping the default 
setting and pushing through eval in a function that can be called from 
`bootstrap.conf', or more robustly by supporting autoconf address@hidden@' 
substitutions.

Also, the substitution function doesn't work properly unless `$build_aux' has 
the same relative path in the parent project as in the gnulib module tree (i.e. 
build-aux).

14. Updating
============

There's no obvious way for bootstrap to update itself.  Since we got to some 
lengths to install the `gnulib' subproject that it comes from, it should at 
least be able to warn that it is out of date even if a self-update is not 
possible - is it even possible (let alone portable) for a script to copy 
something over itself while running, and then re-exec to pick up the changes?

Cheers,
-- 
Gary V. Vaughan (address@hidden)

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

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