Re: building groff with GNU Make and *BSD Make

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Tue, Mar 29, 2022 at 05:59:07AM +1100:

> I'm going to drop a lot of the thread because I don't have anything
> further to add to a lot of it.

Totally fine, i'm usually doing the same.

[...]
> I took the time to read the OpenBSD make(1) page[1] and found the
> following.
> 
> "Distinct target names are treated separately, even though they might
> correspond to the same file in the file system. This can cause excessive
> rebuilds of some targets, and bogus races in parallel mode. This can
> also prevent make from finding a rule to solve a dependency if the
> target name is not exactly the same as the dependency."
> 
> This sounds like exactly the issue that sent you down the printf/gdb
> rathole--is that right?

Yes.  I guess i missed that paragraph.

[...]
> At the same time it does strike me as unfortunate that the synonymy of
> ./file, ././file, and ./././file won't be recognized.  I can see such
> things being the product of macro expansions.

That would need looking at in particular cases.  I doubt that the
groff build system is so complicated that there isn't a simple
solution for that, and if there is, it will also improve the
overall uniformity of the Makefile.

[...]
> Incidentally, I found out why I keep sticking "$<" variables where
> OpenBSD make doesn't want to see them, and why I think it has the
> meaning I've attached to it.
> 
> ...I was remembering the GNU Make manual.  :-/
> 
> "$<
> 
>     The name of the first prerequisite. If the target got its recipe
>     from an implicit rule, this will be the first prerequisite added by
>     the implicit rule (see Implicit Rules)."[2]

Yes.  Using $< outside suffix rules is a typical GNUism.

[...]
> A couple of my pending commits migrate them _all_ to DOC_GROFF_ONLY, and
> then rename all of them back to DOC_GROFF, killing off the original.

I'm looking forward to that, it's a nice simplification even if you
don't consider portability.

> Amidst all that I'm dumping all the `lf`-injecting sed-foolery.

Hurray.  Those manipulations were ugly indeed.

[...]
> Here's another thing I noticed about $<.  The OpenBSD make(1) page
> _seems_ to say that I _can_ use $< in a target rule, _as long as_ I
> have a suffix rule, even predefined one supplied my itself.
> 
> Quoth the page:
> 
>       For instance, with the following Makefile, describing a C
>       program compiled from sources a.c and b.c, with header file a.h:
> 
>       .SUFFIXES: .c .o .c.o: ${CC} ${CFLAGS} -c $<
> 
>       prog: a.o b.o
>               ${CC} ${CFLAGS} -o $@ a.o b.o
> 
>       a.o b.o: a.h
> 
>       b.o: b.c
>               ${CC} -DFOO ${CFLAGS} -o $@ $<
> 
>       Consider b.o: there is a complete target rule re-creating it
>       from b.c, so it will be compiled using ${CC} -DFOO.
> 
>       Consider a.o: there is no explicit target rule, so make will
>       consider valid transforms. Fortunately, there is an inference
>       rule that can create a.o from a.c, so it will be compiled using
>       ${CC}.
> 
>       Note that extra prerequisites are still taken into account, so
>       both a.o and b.o depend on a.h for re-creation.
> 
> I have to say that I seem to _really_ need this feature.

Without seeing your particular application, i cannot comment on that.
In the particular example from the manual page, using $< in the
non-suffix rule seems needless to me: the final shell command could
simply be changed to

        b.o: b.c
                ${CC} -DFOO ${CFLAGS} -o $@ b.c

or couldn't it for some reason i'm missing?

I'm not sure how portable it is to use $< is in non-suffix rules that
override suffix rules.  It may or may not be reasonably portable; i
don't know since i don't recall ever needing it.  POSIX does not appear
to require support for it.

> Also I want to register a gripe that the traditional suffix rule feature
> seems inadequate in the face of files that are named with multiple
> suffixes, like meref.me.in.

How so?  This just works for me:

   $ ls          
  Makefile     meref.me.in
   $ cat Makefile                                                 
  .SUFFIXES: .me.in .me

  .me.in.me:
        cp $< $@
   $ make meref.me
  cp meref.me.in meref.me
   $ ls
  Makefile     meref.me     meref.me.in

> If I understand correctly, GNU Make's pattern rules (like "%.o: %.c")
> are more accommodating of such practice,

That might be true if you want to use *prefixes*, but i'm not sure why
that would be more accommodating as long as you only use *suffixes*.
For suffixes, the GNU-only syntax looks equivalent to me, just less
portable.

> but I see no suggestion that this is supported at all by OpenBSD Make.

It is GNU-only syntax not supported by other make implementations:

   $ ls
  Makefile     Makefile.gnu meref.me.in
   $ cat Makefile.gnu                                             
  %.me: %.me.in
        cp $< $@
   $ make -f Makefile.gnu meref.me 
  make: don't know how to make meref.me
   $ gmake -f Makefile.gnu meref.me
  cp meref.me.in meref.me
   $ ls
  Makefile     Makefile.gnu meref.me     meref.me.in

>> But beware that $? can have surpising effects in rules that contain
>> more then one prerequisite because the shell commands executed will
>> then vary according to which prerequisite(s) are out of date.
>> That's not a problem in the case at hand because when there is
>> exactly one prerequisite, the shell code will get executed if and
>> only if that single prerequisite is outdated, so $? will always
>> expand to the same string for such a rule.

> Yes, this has blown up in my face several times over the past few
> days as I tried to do as much as possible with suffix rules.

There are a few rare situations where you might use $? in suffix
rules, but in the usual cases, suffix rules use $<, not $?.

The $? variable is sometimes useful in non-suffix rules, especially
when they only have a single target.  But even there, using the
explicit filename is often simpler, clearer, and more robust
unless you are doing something special.

[...]
> The amount of debugging output that GNU Make produces is truly
> horrifying.  But I can't say it's unnecessary...

Same for OpenBSD make(1).

>> I guess shortly before we push out rc2, i also ought to test on SUN
>> Solaris 10 and Oracle Solaris 11.  I doubt that i'll do that at short
>> intervals, though, as it causes more work than testing on OpenBSD,
>> even if all goes smotthly, which rarely happens on those platforms.

> If you'd like--I'm okay with landing rc2 _before_ the build's been
> tested on Solaris,

I would deem that unwise.  Solaris is likely to reveal non-trivial
portability issues, so asking people to test first and then invalidate
all that testing because changes have to be made after finally testing
on Solaris would be really unfortunate.

> and if we get good feedback from user_s of other
> OSes, we can address the Solaris portability issues and then proceed
> swiftly, I hope, to the next stage.

Testing on Solaris beforehand, sorting out whatever issues show up there,
then proceed to asking users to test on all other platforms stands a
much better chance of getting away with just rc2 and without bothering
users with another rc3 afterwards.

Is there anything wrong with giving me a heads-up for Solaris testing
a few weeks before the rc?

[...]
> Finally, I installed Debian's "bmake" package which is apparently
> NetBSD's make.  It's man page seems distinguishable from OpenBSD's.
> Do you think it would be useful to help me catch portability issues
> to OpenBSD before you do?

I'm not completely sure because i'm not a make(1) specialist but i
suspect gmake(1) is the odd one out and all other make(1) implementations
are significantly closer to each other than they are to gmake(1).

There are certainly some features that are unique to OpenBSD make,
FreeBSD make, NetBSD make, and (maybe, not sure) Solaris make,
but the portable subset should be fairly well supported by all of
them and also by gmake(1).

Additional testing can never hurt.

Then again, if we test on Solaris, OpenBSD, and Linux before the
release candidate, then i expect the risk of finding more issues
on FreeBSD or NetBSD is fairly low though not zero.

For the RC, i expect i will be able to elicit FreeBSD and NetBSD and MacOS
test reports by asking a small number of FreeBSD and NetBSD developers
(who regularly help with mandoc testing, too) to test the groff rc.
I'd hate to have to ask them to test more than one rc, though, unless
they find issues on those platforms, so i'd like to get rid of Solaris
and OpenBSD issues before enlisting other BSD folks for rc testing.

Yours,
  Ingo