From: "Gary V. Vaughan" <gary@vaughan.pe>
To: Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org
Subject: Re: bootstrap/autogen.sh and git submodules
Date: Sun, 3 Mar 2019 11:01:35 -0800 [thread overview]
Message-ID: <45A2F6BD-DDBD-4753-9076-E55CA012095D@vaughan.pe> (raw)
In-Reply-To: <2684078.KdmCAigxga@omega>
> On Mar 3, 2019, at 10:03 AM, Bruno Haible <bruno@clisp.org> 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.
Cheers,
Gary
next prev parent reply other threads:[~2019-03-03 19:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-03 18:03 bootstrap/autogen.sh and git submodules Bruno Haible
2019-03-03 19:01 ` Gary V. Vaughan [this message]
2019-03-03 21:50 ` Bruno Haible
2019-03-03 20:13 ` Tim Rühsen
2019-03-04 7:42 ` Bernhard Voelker
2019-04-01 15:54 ` Bruno Haible
2019-04-01 15:39 ` Bruno Haible
2019-04-02 16:36 ` Daiki Ueno
2019-04-02 17:55 ` Bruno Haible
2019-04-26 22:57 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45A2F6BD-DDBD-4753-9076-E55CA012095D@vaughan.pe \
--to=gary@vaughan.pe \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).