Hi Paul, Thanks--this is helpful!
At 2026-07-28T15:03:55-0700, Paul Eggert wrote: > On 2026-07-28 11:44, G. Branden Robinson wrote: > > > Is there an Automake variable I can add as a prerequisite of > > libgroff.a? > > If I understand things correctly, the .h files are not direct > prerequisites of libgroff.a; instead, they are direct prerequisites of > the relevant .o files, which in turn are prereqs of libgroff.a. That's what it looks like. > So, maybe changes lines like this: > > src/libs/libgroff/libgroff_a-relocate.$(OBJEXT): defs.h > > to lines like this: > > src/libs/libgroff/libgroff_a-relocate.$(OBJEXT): $(BUILT_SOURCES) > > and add a similar rule for src/libs/libgroff/libgroff_a-font.$(OBJEXT). Hmm! Okay, I'll think about the implications here. > I don't know whether groff assumes GNU Make, so this idea might not be > quite right for you. groff's build actually does work with BSD Make, a property I'd like to preserve if possible. I have walked to the precipice of disclaiming support for it once before, however, due to the sheer perversity of double-suffix rules. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.25.0.rc1#n313 If its maintainers indulge any further act of GNU and/or POSIX incompatibility, I shall interpret it as a spiteful, deliberate effort to drive off users, and leave them to their toybox. (Not sandbox. Toybox.[1]) > The basic problem here, by the way, is that Automake automatically > makes overall targets like 'all' depend on $(BUILT_SOURCES), but does > not do the same for subsidiary targets like doc/groff-man-pages.pdf. > If you don't want to mess with dependencies (quite understandable), > your best answer might be "Don't do that." I.e., don't try to build > individual targets until after you've done a plain "make". Hmm. That would be a nice thing to support; later in the thread where Richard Purdie brought this problem to my attention, he raised a technique that I had used before in a scattershot and ad hoc manner. <https://lists.gnu.org/archive/html/groff/2026-07/msg00079.html>: >>> One slightly tedious but effective way to check things is to script >>> a "make clean; make XXX" iteration over all the possible make >>> targets for the source tree and see if they all build. That would >>> verify things currently work but still doesn't protect against >>> regressions. It is a hard problem. I'd like to keep that weapon at our disposal. Maybe what I need to do is audit our source tree for post-C99 header files we're using and have to date hand-wavingly relied upon <config.h> to drag in for us. For example, src/libs/libgroff/font.cpp #includes <stdcountof.h> and really does use `countof()`. That feels like the right thing to do in any case. I don't know if that will help with one of the other ramified problems Richard observed, though. CC lib/libgnu_a-c32isalnum.o In file included from lib/c32isalnum.c:26: lib/c32is-impl.h:35:10: fatal error: unictype.h: No such file or directory 35 | #include "unictype.h" Any idea about that one? Regards, Branden [1] https://landley.net/toybox/
signature.asc
Description: PGP signature
