> On Mar 3, 2019, at 10:03 AM, Bruno Haible <br...@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
