[Top][All Lists]

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

Re: bootstrap/autogen.sh and git submodules

From: Gary V. Vaughan
Subject: Re: bootstrap/autogen.sh and git submodules
Date: Sun, 3 Mar 2019 11:01:35 -0800

> On Mar 3, 2019, at 10:03 AM, Bruno Haible <address@hidden> wrote:
> Hi,
> When gnulib is used in a package, often the maintainers of that package
> use it via a git submodule, because that enables them to upgrade to newer
> versions of gnulib when they want to (and have a failsafe build between
> these upgrades), rather than having to adapt to gnulib changes at any moment.
> Even if it's only the imported file list which has changed, which might
> require an update to the package's .gitignore file.
> The use of git submodules, however, has three problems:
>  1) There are two use-cases of bootstrap/autogen.sh (the name does not 
> matter):
>       - first-time checkout and build of the sources,
>       - repeated build, possibly after modifying something in the submodule.
>     Currently bootstrap is optimized for the first one, and requires clumsy
>     recipes for the second one. Such as:
>       $ GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git
>  2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
>     not help doing this. I have to keep a command in a cheat-sheet:
>       $ (cd gnulib && git fetch && git merge origin/master); git add gnulib
>  3) As can be seen in the recent thread, there is considerable disagreement
>     regarding the handling of git submodules. Akim wants a fatal error when
>     some git submodules have not been initialized, whereas Tim hates this.
> I would propose to split the common bootstrap or autogen.sh into two
> programs that can be invoked independently:
>  1. A program that deals only with the git submodules.
>  2. A program that only generates files (or, regarding PO files, fetches
>     files that are not kept in git).
> The developer should have the ability to set an environment variable
> (GNULIB_SRCDIR or GNULIB_TOOL), to be used by both programs.
> Advantages:
>  - Developers can test modified gnulib sources without running through
>    hoops.
>  - Developers will have an easy way to upgrade to a newer gnulib version.
>  - Different project policies regarding submodules are isolated in one place
>    and thus have no influence on the gnulib-tool invocation, the PO file
>    handling, etc.
> Disadvantages:
>  - The README-HACKING file will have to list two commands instead of one,
>    for the first-time checkout.
> What's your opinion?
> I'd like to hear your voices, before I modify the autogen.sh scripts that
> I maintain. I won't touch 'bootstrap' (not my domain).
> Bruno

Hi Bruno,

It’s been so long since I maintained a gnulib client project that I feel barely 
qualified to offer an opinion here... I’m likely misunderstanding the question. 
I don’t even know what ./autogen.sh is for?

But answering as best I can purely for completeness’ sake, and assuming my 
memory is behaving well, I found using my bootstrap rewrite alone (usually with 
additional function overrides or wrappers in bootstrap.conf) to be entirely 
sufficient for:

1. running on a freshly cloned working copy to set everything up ready for 
./configure && make

2. rebootstrapping after updating submodules

3. regenerating itself from an updated gnulib-modules/bootstrap submodule from 
time to time

Even so, after the Makefiles were configured, even editing autotools input 
files would not require rebootstrapping, so I really only needed to run 
bootstrap a few times per year per project when updated Automake on my laptop 
or gnulib submodule hashref in a working copy or similar. This is totally 
acceptable from my perspective, and doesn’t require any additional tooling or 
driver scripts.


reply via email to

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