At 2026-07-21T15:32:53+0900, Nguyễn Gia Phong wrote:
> On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote:
> > At 2026-07-21T14:07:10+0900, Nguyễn Gia Phong wrote:
> > > Alternatively, I'm trying to switch to building from Git (we are
> > > trying to avoid artefacts like generated configure where possible)
> > > and without the .git directory (which is not reproducible)
> > > configure is failing to find the version:
> >
> > Right. You now need to specify `--enable-maintainer-mode` to
> > "configure" when building from Git.
> >
> > In my next push, this will be clearer. Here's an exhibit from my
> > working copy.
> >
> > INSTALL.REPO: Document `--enable-maintainer-mode`.
>
> Thanks, though looking at e2cd638955de ("doc/doc.am:
> Employ `MAINTAINER_MODE`.") this only affects requiring
> ImageMagick as a dependency.For now. There may already exist other "informal" maintainer-mode stuff we should bring under the governance of the `MAINTAINER_MODE` Automake macro, and further such things may arise in the future. One existing instance I can think of is the generation of the Bison/YACC grammars for eqn, pic, and refer. See a recent commit: commit baac1d37e9cbf38c786a89e34201bd9cce0ec19f Author: G. Branden Robinson <[email protected]> Date: Thu Jul 2 12:12:37 2026 -0500 [eqn,pic,refer]: Clean out-of-source build trees. ...better. * src/preproc/eqn/eqn.am: * src/preproc/pic/pic.am: * src/preproc/refer/refer.am: Improve clean behavior, deleting YACC/ Bison-generated files _only_ from an out-of-source build tree. Because they are shipped in the distribution archive, only the "maintainer-clean" target should remove them from the source tree. Add new macros `GROFF_{EQN,PIC,REFER}_YACC_FILES` to track these artifacts. Redefine `MAINTAINERCLEANFILES` in terms of these new macros. Add `mostlyclean-{eqn,pic,refer}` targets to perform the cleaning. Add these new targets as dependencies of `mostlyclean-local`. With this commit, the only files left behind after a command sequence like this... rm -r build mkdir build cd build ../configure make make clean ...are a bunch of ".dirstamp" and/or ".Po" files, which are GNU Automake's business to deal with. With `MAINTAINER_MODE`, we might be able to make the foregoing even more scrupulous. > In the spirit of not relying on pregenerated artifact, Guix does want > this flag. Understood. I think Colin Watson has the groff packages for Debian doing the same thing already. > On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote: > > At 2026-07-21T14:07:10+0900, Nguyễn Gia Phong wrote: > > > How is this version string constructed? > > > > README: > > The version number is given in the file ".tarball-version" if > > you are building from a distribution archive; otherwise, > > building from its Git repository stores it in the file > > ".version". > > > > If you're doing an out-of-tree build, then the presence of > > ".version" in your Git working copy can confuse a human > > I'm speaking for the automated build pipeline here. On Guix, if a > package is built from a Git checkout, a fresh clone would be made, > then the .git directory shall be removed, hence the following won't > work. The .version file is not placed in the ".git" directory, but the root of the build tree, wherever that is. I could have been clearer; my usual build tree happens to be a _sub_directory of my working copy. > I've resulted to writing to .tarball-version instead and the build and > tests succeeded. Please let me know if this has any unintended > effect. None that I know of, but I'm nervous about the practice. If your build from the repository is failing to properly populate ".version", I'm strongly interested to know the failure mode. > On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote: > > At 2026-07-21T14:07:10+0900, Nguyễn Gia Phong wrote: > > There is no rc2 tarball; I haven't published one. If the issues > > Alexis found are the only ones that came up, my next distribution > > archive release will be 1.25.0 final. > > Sorry for being unclear, I meant to ask for you to publish the rc2 > so distros will know the 1.25.0 tarball (which will differ only > in the version string) will work. It does not matter now for Guix at > least because we can switch to building from the Git checkout. The rc1 distribution archive _does_ work in some scenarios; I know because I tested it myself. Admittedly, I had an existing groff installation in my build environment, so the build found the "wrong" soelim(1)[1] when generating the man pages, and I also had ImageMagick installed, so any spurious rebuild of "line-layout.png" succeeded. Alexis's report prompted me to test a build in a more slimmed-down environment, which is how I tested the fixes I pushed. Regards, Branden [1] Any "soelim" should work, even one from AT&T troff. Unless you're cross-compiling groff, in which case you must define the Make macro `SOELIMBIN` to point to a soelim(1) that the host can run. However, there might be unsolved problems with cross-compiling groff; I haven't attempted it myself and, as far as I can recall I've never seen a report from anyone who did.
signature.asc
Description: PGP signature
