Re: building groff with GNU Make and *BSD Make

[Ingo Schwarze]

Hi Larry,

Larry McVoy wrote on Mon, Mar 28, 2022 at 12:42:15PM -0700:
> On Tue, Mar 29, 2022 at 06:26:14AM +1100, G. Branden Robinson wrote:
>> At 2022-03-28T12:11:32-0700, Larry McVoy wrote:

>>> I'm a little late, are you guys trying to make things build with
>>> different make(1) implementations?

>> Yes.  Apparently that has worked in the past and does again after Ingo's
>> commits of the past week.

>>> Because that is the path to heartache.

>> I'm learning that.  :-|

> And you will _keep_ learning it, over and over.

You are exaggerating.  Yes, the POSIX specification of make(1) is
not great and it is hard to use for some tasks that occur in *very*
complicated build systems.

But the tasks that the groff build system needs to perform are
simple throughout, and it is not really a problem to perform them
in a portable way.

>>> Just pick one, we picked GNU make, not my favorite by any stretch but
>>> it runs everywhere.  Build the makefiles for that make and call it a
>>> day.

>> Some people will sign a thousand EULAs before touching one copylefted
>> byte.

No doubt all kinds of people exist, but i'm not sure i personally know
any people who would subscribe to that particular philosophy.

>> That doesn't describe Ingo, but it does describe some of the
>> people he works with.

No, that is not true.  All OpenBSD developers by far prefer the GPL
to any kind of proprietary EULA, and the same applies to all FreeBSD,
NetBSD, DragonFly, and Illumos developers i have been working with.
Of course i can't speak for all *BSD developers because there are many
i never met, but finding one who prefers EULAs over the GPL would seem
like a surprising and rather weird exception to me.

> "And that's why they can't have nice things".

This is badly misleading.

I'm not saying "if GNU troff required gmake(1) to build, that would
mean GNU troff would have to be deleted from the OpenBSD ports tree".
Quite to the contrary, a very rough estimate is that out of the about ten
thousand packages in the OpenBSD ports tree, about one thousand already
require gmake(1) and use it to build as we speak.  So if some project
decides "we only support gmake(1)" and if they make their Makefiles so
non-portable that gmake(1) is indeed required - no matter whether they
have good reasons or merely act in a thoughtless way - then of course
we use gmake(1).

What i'm saying is "GNU troff has no good reason to require gmake(1),
everything can be done just fine in a portable way, and when portability
is possible with no significant downside, then portability should
be provided."  Or to say the same in different words: Do not go the
"non-portable, GNU only" way unless there is a significant reason to.

> If the openbsd people want to be that weird, they get to maintain
> their own port of groff.

Guess what?  That is *exactly* what i have already been doing for about
a decade: maintaining our port of groff, and other OpenBSD developers
have been doing that for another 15 years before i took over, and other
BSD projects have been doing that for several more years before OpenBSD
was forked from NetBSD and from 4.4BSD, so much so that in some respects,
old BSD releases provide more information about groff history than even
the official groff git repository.

That maintenance work includes feeding as much as possible back upstream
and working hard to minimize our local patches.  A small number of small
local patches that are inadequate for upstream are unavoidable, but these
local patches will *shrink* rather than grow with the next groff release:
the current official OpenBSD groff-1.22.4 patches +248 -209 lines in 7
files, including several bugfixes that have also been committed upstream.
My work-in-progress port of the git head patches +132 -126 lines in five
files, including stuff like setting the operating system name in manual
page footers and the like.  I hope to shrink patches even further in
the future.

> groff itself is copylefted, is it not?  So if we're already over the
> copyleft "cliff", how does GNU make screw things up?

Copyleft software can be included in the ports tree of *any* BSD project,
there is no problem with that at all, so GNU make does not screw things
up in that sense.  In fact, GNU make is available in the ports trees of
all the BSD projects.

OpenBSD has a policy to not include any new GPL software into the
OpenBSD base system as long as there is any way to avoid it, but that
is completely unrelated to all that we are discussing here.

> The idea that you, someone working on groff for free, have to jump 
> through more hoops to keep things going because of fear-of-copyleft,
> is just insane.  Completely unreasonable, bigger fish to fry.

Not jump through hoops, just adhere to standard portability practice.

What next?  Build only with Bash, GNU awk, GNU sed, GNU grep,
GNU mkdir, Bison, GCC, GNU ld, GNU ar, and glibc?  How is not being
gratuitiously non-portable with respect to make(1) different from not
being gratuitiously non-portable in any other respect?

Yours,
  Ingo