Hi Branden, Have things worked out for you by now? Is the .tarball-version workflow clear? Should we document it better in the git-version-gen script?
Bruno =========================================================================== I wrote: > > > By the way, if submodules are not what you want, i.e. if you always > > > want to use the newest gnulib, I suggest to use the > > > gnulib/top/gitsub.sh script. > > > > I have no principled objection to submodules; the decision to use them > > (well, just this one, for gnulib) was taken before I joined groff > > development. > > OK, let's stick to that, then. Submodules. > > > configure.ac says this. > > > > AC_INIT([GNU roff], > > m4_esyscmd([build-aux/git-version-gen --fallback 1.23.0.rc1 \ > > --prefix "" .tarball-version]), > > http://savannah.gnu.org/bugs/?group=groff, > > [groff]) > > Ah, you want to use git-version-gen to infer the version of groff, not > the version of gnulib! This means that we have two independent topics, > then: > (I) git-version-gen and configure.ac > (II) bootstrap and wget vs. 'git submodule'. > From your original mail I got the impression that those were related, > leading to confusing discussions. > > ==================================== > (I) git-version-gen and configure.ac > ==================================== > > Many packages (autoconf, bison, coreutils, diffutils, gettext, guix, gzip, > libidn, libtool, m4, patch, wget, ...) use the following in their > configure.ac: > > m4_esyscmd([build-aux/git-version-gen .tarball-version]) > > Groff uses --prefix "", since its 'git tags' list doesn't have a prefix, > and it uses option '--fallback 1.23.0.rc1'. > Now, let's look at the outcome, depending on each of the 4 cases: > > - .git directory present, git program present: > coreutils: 9.1.25-93e099e > groff: 1.23.0.rc1.2532-73999 > > - .git directory present, git program absent: > coreutils: UNKNOWN > groff: 1.23.0.rc1 > > - .git directory removed, git program present: > coreutils: UNKNOWN > groff: UNKNOWN > > - .git directory removed, git program absent: > coreutils: UNKNOWN > groff: 1.23.0.rc1 > > The effect of your patch is to use the fallback value in the 3rd case too. > > But the use-case of the 3rd and 4th case is when the user has unpacked a > tarball. But the tarball is supposed to contain a file '.tarball-version'; > *that* is where the fallback is supposed to come from. > > So, to me it appears that groff should package a file '.tarball-version' > in the tarballs, like the mentioned GNU packages do; then > - your git-version-gen invocation in configure.ac snippet would work, > - you would not need the --fallback option, > - and thus you would not need to modify the configure.ac (which is > tracked in version control) each time you make a prerelease. > > I agree that the workflow with .tarball-version is not well documented; > here's how I use it in GNU gettext: [1]. > > But if you want to have another workflow, where you put the version into > configure.ac instead of .tarball-version, then > 1) You need to explain what the advantages are compared to the other > workflow (since it costs time to maintain two different approaches > for the same objective), > 2) four changes are needed in build-aux/git-version-gen: > - your patch to the 'elif' line, > - a modification to the help text for --fallback, > - making the '.tarball-version' argument optional instead of mandatory, > - comment changes that indicate how to use your alternate workflow. > > ======================= > (II) bootstrap and wget > ======================= > > > > - You have submodule information in the parent git repository (groff). > > > > Yes. But, importantly, _not in the snapshot archives that Savannah cgit > > generates_. > > Why do you insist on using cgit snapshot archives, when everyone else uses > 'git clone'? > > Everyone uses 'git clone', because when a developer has checked out the > sources and done a build of groff, the chances are high that they will want > to a build again, say, two weeks later. By then, you will have updated the > gnulib repository reference (of the submodule). Thus, the developer will > need that new snapshot of gnulib. By downloading the cgit snapshot archives > it will require him 8 MB of download; by doing a "git pull" in the submodule > it will be something like 0.1 MB. In other words, 'git clone' is prepared for > incremental updates, whereas cgit snapshot archives are not. > > > After resolving this, I had plans to go complain to the Savannah > > administrators that the snapshot archives they generate on demand > > neither (1) recurse through submodules nor (2) provide a > > ".tarball-submodules" file with the requisite information such that > > users can construct URLs and retrieve those bits themselves. > > cgit is not developed by the Savannah admins. Are you suggesting that the > Savannah admins fork cgit? > > > > - let 'bootstrap' abstain from any git operation; that implies passing > > > not only --gnulib-srcdir but also --no-git. > > > > Adding '--no-git' to '--gnulib-srcdir' doesn't seem to change anything > > for me > > That's because you had apparently no local changes to gnulib. If you have > local modifications, '--no-git' is essential, if you don't want to get crazy. > > Bruno > > [1] > https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=Admin/release-steps
