Re: how to manage make(1) dependencies on gnulib-generated header files

--qk4es4h7hzvdglb6
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: how to manage make(1) dependencies on gnulib-generated header
 files
MIME-Version: 1.0

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:
>=20
> > Is there an Automake variable I can add as a prerequisite of
> > libgroff.a?
>=20
> 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:
>=20
> src/libs/libgroff/libgroff_a-relocate.$(OBJEXT): defs.h
>=20
> to lines like this:
>=20
> src/libs/libgroff/libgroff_a-relocate.$(OBJEXT): $(BUILT_SOURCES)
>=20
> 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=3D1.25.0=
=2Erc1#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/

--qk4es4h7hzvdglb6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmppKzIACgkQ0Z6cfXEm
bc6fHRAArsK8tSwRAgVQxcBVTL2JygOtJyfx7LpoYrThjsWu3L1yx+vJryO9KLtb
hxGIyaiMQ0YWdq+AnianqDhxheBlYffYCVMHJL4OtF7JHkNpqLslJSfvis+e2rL1
n553l+CKQNgZAXfDdiD047fEKpaOO+o0+TybcPzF3TewZTaQ5k4pbgv6357H0h8V
wVWGro6RneRIljGLBcZomGNe/tIRXLrdGyjSXOWzeGzqHqo/+FxULZodtloNzFUr
i6X7QXs5cZJKlEc65zbqcoAQbUlUXN9rV1Y+zRKkPi+vu3MUT77TkOfRVwebUOpJ
MoLvtwPOo+iJL2ngx5IpTpAMbC0QVND6xcBI8YpxHN7x19ThAT4mOjJLVYyD56/p
tDgXgNkmwBtVTD8cfoNBUTEmXEi898MPCCCBinaiqaRIQ5h5Rx8XWEsOaFLVjN3l
a7raviuUHurAlUE61grY1VmE9tUen0H2QtoxGkY1IqqGMgdJas6g18HJ36ADFFo7
W5Wv2MJ81It0fkAH3vsqYpAJiQ5NgUuhT4Sk3Q6s9Qhl/pFPPZnSWjSeULhtaAjP
0KErUEIQHZte1y/CIEGNxlpDQWKCx0fEtGXtlU2R2VWtjrJeJ98+MNsKl88syiXq
LN4xxrJR8YZlAc453htjnXkNA/t+6CcbT3AaIEtaKAg0hbG7uI4=
=nO8n
-----END PGP SIGNATURE-----

--qk4es4h7hzvdglb6--