[bug #66583] [PATCH] allow building groff without makeinfo

[G. Branden Robinson]

Follow-up Comment #43, bug #66583 (group groff):

Hi Alex,

At 2024-12-30T01:24:39+0100, Alejandro Colomar wrote:
> On Sun, Dec 29, 2024 at 05:47:41PM -0500, G. Branden Robinson wrote:
>> Follow-up Comment #33, bug #66583 (group groff):
>> To lead with a summary: I partly disagree with your rants,
>
> From what I've read, you agree quite a lot, actually.

Well, I didn't want to risk dashing your hopes later.  ;-)

> I can't reproduce it on Devuan testing (Excalibur), which I installed
> in my desktop yesterday.
>
> I can't reproduce it either on a Docker container with Devuan stable
> (Daedalus).
>
> But I can reproduce it on a fully-updated Devuan stable machine (my
> laptop).  Even on a fresh new git clone of groff it reproduces.  And
> even after running `apt-get build-dep --no-install-recommends groff`
> to install all dependencies for building groff.
>
> I'll receive a new laptop in a few days.  There, I plan to install
> Devuan stable again.  I'll try to reproduce it there on the clean
> install.  I'll let you know if it reproduces there.

Okay.  I'll return to this point below.  I have a hunch.

[rearranging a bit]

> I don't know that build system [imake], and don't know what I would
> think of it.  But yeah, the "probing the system" part of a configure
> script, I like it.  In my build systems, I run it as part of make(1),
> so that the probing is run every time you run make(1) (it's quite fast
> compared to the actual build), so that if the system gets an upgrade
> between make(1) runs, the probing is accurate to the current system.

I think a lot of people prefer a separate ./configure (probing) step
because generally the characteristic parameters of the system don't
change between that time and the subsequent `make` command, so there's
no reason to spend _any_ time re-probing.  I like the separation of
concerns.  There may also be a factor of historical inertia: Autoconf
has had a configuration caching feature (one that persists between runs
of the ./configure script, I mean) for a long time, but I don't know if
it goes all the way back to the first releases.  Those were before my
time.  It could be that "./configure && make" was such a famously
winning formula that no one wanted to mess with it.

Another factor that's tricky about incorporating probing into Makefiles
is that, unless Autoconf and system vendors carry the Unix Philosophy of
Everything Is a File much farther, it's hard to tell if something
"configgy" is out of date.  How does a Makefile know if packages on the
system have been upgraded since it last probed?  How does it know
whether any of those package upgrades are relevant?

One can indeed do what you do, and re-probe everything all the time.
For me, that would likely be unsatisfactory--for projects I work on, the
time spent running "./configure" is _not_ negligible.

All of that said, I think you do have a point that Autoconf might have
gotten a bit overloaded.  The parameters of the system, like "what's my
compiler?" and "how does my libc behave?" are clearly distinguishable
from user decisions like "I don't want the docs".

But back on the gripping hand, I can see how the line between these gets
blurry in cases like, "I have both Clang and GCC installed, and I
want to use <preference>".

If I had a magic bullet, I'd load and fire it.

> Also, the list of targets should be unconditional, and configure
> shouldn't mess with them.  Targets are make(1)'s business.  But
> usually, ./configure does change them significanty.
>
> It's [this] other part what I dislike.

I trust you realize that you and onf are arguing diametrically opposed
objectives here.  He _absolutely_ wants to drive target selection from
the "./configure" script.  Or did.  The plethora of new make(1) target
names he's proposed, he might regard as a complete replacement for that
approach.

[I'm assuming a gender pronoun here.  Let me know if it should change.]

>> That _is_ guessing what you want to do.  But "all the usual stuff"
>> is a good guess.  That's what a default make target is _for_.
>
> That's as much guess as I can tolerate.  But that guessing should be a
> one-time guess.  That is, the maintainer should decide what `make all`
> does, and then that should be done on every system.  If the configure
> script decides what's to be done based on my system, we're in trouble.

I think there's a limit to that principle, one which groff hits in
several respects.  If I were to apply it literally, I'd have to drop
from the source tree everything that exercises an optional dependency.
We have so many of those that we have several _NOTICE macros to warn
users about what they'll be missing because they don't have them.

https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n222
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n245
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n321
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n407
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n520
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n1729
https://git.savannah.gnu.org/cgit/groff.git/tree/m4/groff.m4?h=1.23.0#n1867

I suspect Deri would be cross with me if I dropped gropdf from the groff
distribution.  And others would get mad if I cause the build to fail
hard just because some output driver they don't use (like grohtml)
couldn't be constructed.

> So, I want `make all` to build _all_ the usual stuff, not just the part
> that the configure script thinks my system can build.

This sounds like another way of saying you want to populate the
dependencies of the default target differently, overriding those that
the ./configure script in its present form omits.

More precisely, you want the deps of the default target to not vary,
ever, and just have the build fail hard during make(1) if _anything_
won't build.  That's going to be a shocking change for our users, and
it's going to amount to supporting only one configuration of groff in
this respect (you get grohtml, gropdf, X11, and URW font support,
or you get a failing build).

That's not a _horrible_ idea.  I like the thought of reducing the
dimensionality of the configuration space.  But those knobs were put in
there in the first place on purpose, because different groff user
communities (mainly GNU/Linux distributors, I think), just didn't want
to bother with certain prerequisites.  groff's development philosophy
has been to be accommodating.

I suggest you pitch this change of approach to the groff@ mailing list
and see what sort of response you get.

I allot myself a quota of potentially user-angering changes and I prefer
to spend my allocation on those that I value highly.  My inclination is
keep things as-is in this respect, except for reducing grohtml's
dependencies by rearchitecting it (to eliminate pre-grohtml(1), mainly).
But that's a long-term project.

> It's not related to the bug.  Just part of the rant against autotools
> being brain damaged.  One of the problems that keeps me thinking that
> autotools should die, and be replaced by carefully written GNU
> makefiles.
[...]
> Again, not a problem in this specific bug.  Just another problem that
> gets me mad with autotools.  It should die.

Okay.  Replacing Autotools is not an objective of mine.

> I don't see it in the makefiles (god save me from trying to read them).
> That's what I experience in my laptop.  As in, I clone the repo, then
> bootstrap and configure as always (no args), then `make -j24 -k`, and
> I end up with an error about docs, and no groff binary.
>
> Why?  I don't know.  When I get the new laptop soon, I'll try to
> reproduce on a clean install of Devuan stable.  We'll see.
>
> I'm also puzzled about why it doesn't reproduce on a Docker container.

Okay, coming back to this.  This is just a guess, but I wonder if what
you're encountering is some sort of memory starvation.  On the
debian-devel@ list there's a recent thread about this.  Long story
short, parallelism in CPU cores is outrunning memory provisioning (since
each core wants its own partition of RAM[?]), and since Unix has been
committed to memory overcommit since the first (or at least the earliest
well-known) virtual memory kernel in 3BSD, people are encountering pain.

https://lists.debian.org/debian-devel/2024/11/msg00498.html
https://lists.debian.org/debian-devel/2024/12/msg00092.html

> That it doesn't seem to address the bug I experience, which I can only
> explain as a wrong dependency somewhere.
>
> Since I can't reproduce it anywhere except my laptop, I've tried
> something there: I touched the files that make(1) is having trouble
> building, which were
> touch doc/groff.dvi
> touch doc/groff.pdf
>
> and after that, the build run just fine.

A thing to know is that these are the only two targets that involve a
TeX system, and TeX is _very memory-hungry_.  Compared to groff, anyway.
So it might be getting memory-starved.

> So, some part of the build is a dependency of 'all', and other part is
> 'all' itself.  This is brain damage.  That's causing a hidden
> dependency where all of the recursive build (whatever that is) depends
> on all of the BUILT_SOURCES (whatever that is).  That's the bug.  (Why
> can't I reproduce it elsewhere?  I don't know.  Probably those guesses
> that we mentioned before.)

Before blaming groff's Automake files I'd make sure you know for _sure_
why the build is failing.

> At this point I should mention "Recursive MAke Considered Harmful",
> which is defended by GNU Make's maintainer Paul Smith.

I'm familiar with it, and endorse it as well.

> Please change groff to use a single makefile (may include other
> makefiles, as long as there's a signle make(1) process).

I'm not sure how recursive it really is in Peter Miller's sense.  Here
are all the matches for '$(MAKE)' that I can see:

$ git grep -F '$(MAKE)'
ChangeLog.120:  $(MAKE) and $(MDEFINES) are used.
contrib/mm/Makefile.sim:        $(MAKE) -f Makefile.sub tmacdir=$(tmacdir)
srcdir=$(srcdir) \
contrib/mm/Makefile.sim:        $(MAKE) -f Makefile.sub tmacdir=$(tmacdir)
srcdir=$(srcdir) \
font/devlj4/devlj4.am:  $(MAKE) -f $(devlj4_srcdir)/generate/Makefile \
font/devps/devps.am:      $(MAKE) -f $(devps_srcdir)/generate/Makefile \

1.  A ChangeLog entry.  Ignore.

2.  Two hits in a very old Makefile, unused by groff's build system for
    supporting standalone maintenance of "mm", a _contributed_ hunk of
    the source tree.  I wouldn't be surprised if this file is
    bit-rotted, and since I seem to be the new mm maintainer (I'm the
    only person to have done a lot of work on it since Jörgen Hägg went
    dormant), it might be my prerogative to just rip this out.  See the
    "Makefile.sub" reference?  That's a relic of the old, pre-Automake
    groff build system (see groff 1.22.3).

3.  Two output drivers launch make.  These look like smoking guns until
    you realize that there are in "maintainer-mode" targets upon which
    nothing depends.  Moreover, the Makefiles in question are shipped
    and installed to support users who want to generate groff font
    descriptions for digital fonts they may have lying around and which
    stock groff doesn't know about.  So these Makefiles _have_ to work
    independently of the groff build itself.

Also check this out:

https://git.savannah.gnu.org/cgit/groff.git/tree/Makefile.am?h=1.23.0#n606

The _inclusion_ of the subordinate *.am files, as opposed to "cd"ing
into a subdirectory and running "make" in it--essentially so that you
have one big dependency tree instead of a forest of trees--is exactly
the sort of solution prescribed by Peter Miller.

Possibly the target name "all-recursive" has misled you.  It doesn't
seem to be groff's invention.  Maybe it's a misleading choice on
Automake's part.  Just a guess.

The comment at the other end of that hyperlink is pretty suggestive,
too.  ;-)

If you're not aware of it, please read Bertrand Garrigues's paper on the
use of Automake in groff.  He's the person who ported us to it.

It's in the source tree as "doc/automake.mom", and gets built as a PDF.

> It's not that.  It's that some of autotools guesses are messing the
> deps (probably?).

I don't think we have sufficient evidence to warrant that conclusion
yet.

Regards,
Branden



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66583>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature