building groff with GNU Make and *BSD Make

[G. Branden Robinson]

Hi Ingo,

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

I'll first say that I have _several_ more commits to doc/doc.am pending.
But it takes a lot of time to test them and I'm finding myself with a
very pretty constraint problem in trying to stay within the portability
restrictions you advise.

So in service of that I have some make-related questions and thoughts.

> Yes, i admit there is some fragility in OpenBSD make in this respect.
> 
> Then again, the rule "targets are strings" is much simpler than
> the rule "targets are inodes", in particular since it is common
> to define targets that are not file system objects at all.

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?

> So while our OpenBSD make behavoiur caused fragility and surprise
> here, i suspect GNU make behaviour just causes different complexity,
> fragility, and surprises.  In any case, thinking of targets as strings
> and not hoping that make(1) will magically recognize strings pointing
> to the same file system object is better for portability.

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.

> Also consider that it isn't unusual for a make(1) implementations
> to finish constructing the input graph before they even start to
> investigate which targets are needed for the current run and to
> consider whether each of those is up to date or outdated, and
> there is no real need to inspect the file system before that late
> point in time.  Finally, to realize that two different strings may
> end up pointing to the same file is not even possible by inspecting
> the file if one or both of the names do not yet exist in the file
> system, which is obviously a typical situation for make(1).

This is a good point.

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]

> Fair points all around, so i pushed a DOC_GROFF -> DOC_GROFF_ONLY
> instead for this rule.

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.

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

> >>  4. doc/doc.am, doc/groff-man-pages.* rules:
> >>     Again, we have $< in non-suffix rules, this time not only
> >>     with one, but with many file name arguments.  Amazingly,
> >>     GNU make somehow copes.  Not that what GNU make does makes
> >>     any sense - it appears the $< picks the first dependency
> >>     and silently discards all the others, which is obviously
> >>     the perfect way to shove errors under the carpet - but at
> >>     least it doesn't crash like POSIX make does!  ;-)
> >>     Then again, all that resulted from $< is discarded anyway...
> >>     :-(

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.

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.  If I understand correctly, GNU Make's
pattern rules (like "%.o: %.c") are more accommodating of such practice,
but I see no suggestion that this is supported at all by OpenBSD Make.

> 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.

> > In fact, in my own experiments, DOC_GROFF is no longer even
> > necessary once your changes and a few of my own are made.  So a
> > subsequent commit can simply rename DOC_GROFF_ONLY to DOC_GROFF.
> 
> Yes, getting rid of the execessively complicated DOC_GROFF facility
> would be nice.  A Makefile is not the best venue for holding a sed(1)
> and sh(1) golfing contest.

As noted above, I have work in progress along these lines.

> But yes, you are right that the format and meaning of -d m output
> could be much better documented.

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

> 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, and if we get good feedback from users of other
OSes, we can address the Solaris portability issues and then proceed
swiftly, I hope, to the next stage.

...at which point I want to consider a calendar-based release cadence.
Who knows, maybe we'll find reason to bump the minor version nearly
every time.

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?

Regards,
Branden

[1] https://man.openbsd.org/make
[2] 
https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html#Automatic-Variables

signature.asc
Description: PGP signature