Hi, On 2026-07-21 at 21:48-05:00, G. Branden Robinson wrote: > Ah. In that case your build is neither fish nor fowl: neither a build > from a distribution archive, nor a build from a Git working copy, > because there is no working copy. > > What is the rationale for this sort of build configuration?
The rationals for avoiding the dist archives on Guix were discussed in the following thread. https://yhetil.org/guix-devel/[email protected]/T In brief, (1) generated configure and Makefile are considered build artifacts, which goes against the principle of building from (and thus patching) the preferred form for modification, and (2) version-controled archives are more friendly to Software Heritage (content-addressed VCS archives). (Guix does have content-addressed file archives for tarballs, but our infra is limited, and the distro-agnostic one called ERIS is still under development. Neither is publicly financed in long term like Software Heritage.) As for removing the .git directory, it is for the reproducibility of the checkout directory, as there can be new objects not relevant to the commit of interest in future clones. On 2026-07-21 at 21:48-05:00, G. Branden Robinson wrote: > We've had problems supporting that sort of thing in the past. > > https://lists.gnu.org/archive/html/groff/2022-06/msg00001.html > > The consensus at that time was not to support them, hence the disabled > "snapshot tarballs" via Savannah's cgit interface. > > At 2026-07-22T11:18:56+0900, Nguyễn Gia Phong wrote: > > 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. > > Hmm. If it's that easy, why isn't this already standard practice in > projects using Autoconf? Or is it, and I haven't noticed? I don't know if it will be easy, I was offerring a hand understanding it is not a high priority for Groff. >From the linked thread, how about hardcoding in configure.ac the `build-aux/git-version-gen --fallback' version? This can be done every time a new version number is added to the NEWS file. On 2026-07-21 at 21:48-05:00, G. Branden Robinson wrote: > At 2026-07-22T11:18:56+0900, Nguyễn Gia Phong wrote: > > 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: > > > > contrib/mom/mom.am-MOMPDFMOM = \ > > contrib/mom/mom.am: GROFF_COMMAND=test-groff \ > > -- > > doc/doc.am-DOC_PDFMOM = \ > > doc/doc.am: GROFF_COMMAND=test-groff \ > > [...] pdfmom(1) is growing increasingly poorly named in any event; > it need not format a mom(7) document, and the problem of > forward references does not uniquely afflict PDF generation, either. > > Maybe we should reconsider the tool's scope and purpose, rename it, say, > "regroff", and supply a "test-regroff" script, generated at > configuration time as "test-groff" is. [...] > > In the short term, if "automake.mom" doesn't actually need multi-pass > formatting, then we should move it back to `GROFFBIN`. I don't see any > forward references; the relocated table of contents in the PDF rendering > doesn't count, because that's achieved by PDF-level page resequencing > magic. Thanks, am I understanding correctly that if multi-pass formatting (or any formatting at all) must be done to-be-built groff et al, it has to be disabled under cross-compilation? I am guessing that it is okay to build the PROCESSEDDOCFILES with Groff of the same version (but different e.g. architecture), so could GROFF_COMMAND within an invocation of make be ensured to be GROFFBIN _if_ the latter is provided? test-groff is obviously not executable under cross-build, so alternatively we could copy the host's groff doc files over instead of building them. Best wishes, Phong
signature.asc
Description: PGP signature
