Hi, On 2026-07-21 at 02:00-05:00, G. Branden Robinson wrote: > At 2026-07-21T15:32:53+0900, Nguyễn Gia Phong wrote: > > the .git directory shall be removed, hence the following won't work. > > > > On 2026-07-21 at 00:40-05:00, G. Branden Robinson wrote: > > > Earlier in the file. > > > > > > $ nl -ba Makefile.am | sed -n 509,509p > > > 509 # 'VERSION' is generated by gnulib script git-version-gen > > The .version file is not placed in the ".git" directory, > but the root of the build tree
I was referring to the git-version-gen script, which needs .git
to determine the current tag/commit.
On 2026-07-21 at 02:00-05:00, G. Branden Robinson wrote:
> At 2026-07-21T15:32:53+0900, Nguyễn Gia Phong wrote:
> > 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.
IIUC, both .version and .tarball-version comes from $VERSION,
which in turn is derived from the current Git HEAD in .git.
TBH manually populating a version file is not unusual practice in Guix,
though it'd be lovely if the configure script excepts a --version=...
override flag. If that sounds good, I don't expect it in 1.25,
and can offer a patch.
On 2026-07-21 at 02:00-05:00, G. Branden Robinson wrote:
> 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.
>
> [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.
Similar to Nix, Guix build things in isolated environment,
so there would not be the host's roff unless it's absolutely necessary
(e.g. compiler bootstrapping).
Speaking of cross compilation, it has been broken since at most 1.24
as pdfmom used to build doc/automake.pdf uses test-groff
instead of GROFFBIN, I think:
$ make GROFF_BIN_PATH=... GROFFBIN=.../bin/groff
...
GROFF doc/automake.pdf
sh: line 1: test-groff: command not found
pdfmom: fatal error: test-groff exited with status 127
make[2]: *** [Makefile:19211: doc/automake.pdf] Error 1
...
$ grep -r -B1 -A3 GROFF_COMMAND=test-groff
contrib/mom/mom.am-MOMPDFMOM = \
contrib/mom/mom.am: GROFF_COMMAND=test-groff \
contrib/mom/mom.am- GROFF_COMMAND_PREFIX= \
contrib/mom/mom.am- GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
contrib/mom/mom.am- $(PDFMOMBIN) $(FFLAG) $(MFLAG) -M$(mom_srcdir) -K utf8
-p -e -t \
--
doc/doc.am-DOC_PDFMOM = \
doc/doc.am: GROFF_COMMAND=test-groff \
doc/doc.am- GROFF_COMMAND_PREFIX= \
doc/doc.am- GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
doc/doc.am- $(PDFMOMBIN) $(MFLAG) $(FFLAG) -ww -b $(pdfmomoption) --roff
On 2026-07-21 at 02:00-05:00, G. Branden Robinson wrote:
> At 2026-07-21T15:32:53+0900, Nguyễn Gia Phong wrote:
> > 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.
Thanks for the info!
All the best,
Phong
signature.asc
Description: PGP signature
