bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alejandro Colomar
Subject: Re: [bug #66583] [PATCH] allow building groff without makeinfo
Date: Tue, 31 Dec 2024 15:54:40 +0100

Hi Branden,

On Tue, Dec 31, 2024 at 07:24:03AM -0500, G. Branden Robinson wrote:
> Follow-up Comment #43, bug #66583 (group groff):
> 
> Hi Alex,
> 
> At 2024-12-30T01:24:39+0100, Alejandro Colomar wrote:
> > 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.

That's reasonable.  A configure script that would only (or mainly) do
just probing would be one that I would consider fine.

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

I suspect the separation was due to:

-  Unix systems having more variation from one to another, so many more
   details had to be probed.  These days, I just assume POSIX.1-2024,
   and claim no support for anything that deviates from that.

-  Systems being significantly slower, so that huge number of probes
   took minutes.

These days, for software that doesn't need porting to old systems, you
only need to probe at most a dozen features, which may take
milliseconds.  But for groff, I understand you need to port to very old
systems.

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

In my approach, since everything is done in make(1), I probe the
features of $(CC), which defaults to cc.  If nothing is specified, it
uses the system cc, and probes its features.  If CC=clang is specified,
it probes clang.  On a build system where you separate ./configure and
make, hmmmm, yeah, it gets messy.  Maybe that's a good point in favor of
my merged approach.

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

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

For that, my opinion is:

Provide separate targets, to allow partial builds, e.g.:

        make gropdf
        make grohtml
        ...

If one makes 'all', it should make all.  If you consider that some parts
are interesting enough for certain users, you should provide targets for
them.

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

Yes.

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

You could get partial (or more complete than default) builds with some
targets.  But yes, the default should be one.

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

Yes, GNU/Linux distributors want the build system to correctly guess
what each of them wants.  That's an insane wish, and results in
autotools being so damn complex and hard to use right.

And yes, they would blame you if you change that.  Which is why I won't
push you hard for doing that.  I know what's pushing on the other side.

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

Maybe in the future.  I'll first try to get one of my libraries packaged
for most distros, so I get all the blame.  When I've successfully done
that, I might come back here.

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

Hopefully not.  That laptop is quite new and powerful.  64 GiB RAM shall
be more than enough for anything these days.

I think I also tried building without -j24 the other day, just to check
that it wasn't the multi-process build failing (I've seen for example
shadow.git fail when running `make dist -j24`).

I tried again, just in case, and it still fails on a single process
build.  See at the bottom of this email.

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

See right above.

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

My count is different:

        $ git describe
        1.23.0-2695-g499277778
        $ ./bootstrap >/dev/null 2>&1; echo $?
        0
        $ ./configure >/dev/null 2>&1; echo $?
        0
        $ grep -rl '$(MAKE)'
        ChangeLog.120
        autom4te.cache/output.2
        autom4te.cache/output.4
        autom4te.cache/output.3
        autom4te.cache/output.1
        contrib/mm/Makefile.sim
        Makefile.in
        gnulib/doc/make-stds.texi
        gnulib/build-aux/po/Makefile.in.in
        gnulib/top/GNUmakefile
        gnulib/top/maint.mk
        gnulib/modules/relocatable-prog
        gnulib/modules/verify-tests
        gnulib/ChangeLog
        gnulib/Makefile
        font/devps/devps.am
        font/devlj4/devlj4.am
        configure
        Makefile
        config.log
        $ grep -r '$(MAKE)' | grep -v gnulib | wc -l
        103
        alx@devuan:~/src/gnu/groff/master$ grep -r -B1 '$(MAKE).*all-recursive'
        Makefile.in-all: $(BUILT_SOURCES)
        Makefile.in:    $(MAKE) $(AM_MAKEFLAGS) all-recursive
        --
        Makefile.in-install: $(BUILT_SOURCES)
        Makefile.in:    $(MAKE) $(AM_MAKEFLAGS) install-recursive
        --
        Makefile-all: $(BUILT_SOURCES)
        Makefile:       $(MAKE) $(AM_MAKEFLAGS) all-recursive
        --
        Makefile-install: $(BUILT_SOURCES)
        Makefile:       $(MAKE) $(AM_MAKEFLAGS) install-recursive

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

As far as I can see, the name seems to be really recursive.  See above.

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

Here's the evidence.  This session has been run a couple of hours ago
in my laptop.


Have a lovely new year!
Alex


alx@devuan:~/tmp/groff$ git clone https://git.savannah.gnu.org/git/groff.git 
>/dev/null 2>&1; echo $?
0
alx@devuan:~/tmp/groff$ cd groff/
alx@devuan:~/tmp/groff/groff$ ./bootstrap >/dev/null 2>&1; echo $?
0
alx@devuan:~/tmp/groff/groff$ ./configure >/dev/null 2>&1; echo $?
0
alx@devuan:~/tmp/groff/groff$ free
               total        used        free      shared  buff/cache   available
Mem:        65025216     1493664    63242056      147748     1075748    63531552
Swap:              0           0           0
alx@devuan:~/tmp/groff/groff$ while true; do sleep 20; free; done &
[1] 24273
alx@devuan:~/tmp/groff/groff$ make >/dev/null 2>&1; echo $?
2
alx@devuan:~/tmp/groff/groff$ fg
while true; do
    sleep 20; free;
done
^C
alx@devuan:~/tmp/groff/groff$ free
               total        used        free      shared  buff/cache   available
Mem:        65025216     1488628    63229876      147748     1093544    63536588
Swap:              0           0           0
alx@devuan:~/tmp/groff/groff$ make
  GEN      doc/groff.dvi
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian) 
(preloaded format=etex)
 restricted \write18 enabled.
entering extended mode
(../../../../../doc/groff.dvi.t2d/doc!groff.t2d/dvi/src/groff.texi
(/home/alx/tmp/groff/groff/build-aux/texinfo.tex
Loading texinfo [version 2024-02-10.22]: pdf, fonts, glyphs, page headings,
tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
cross references, insertions, localization, formatting, microtype,
and turning on texinfo input format.) (/home/alx/tmp/groff/groff/doc/txi-en.tex
)
Writing index file groff.cp
[1] [2] (./groff.toc) (./groff.toc [-1]) [-2] Chapter 1 (./groff.aux) [1]
[2] [3]
Writing index file groff.fn
l.804: Undefined cross reference `Setting Registers-snt'.
l.804: Undefined cross reference `Setting Registers-snt'.
l.804: Undefined cross reference `Setting Registers-pg'. [4]
l.853: Undefined cross reference `Line Layout-snt'.
l.853: Undefined cross reference `Line Layout-snt'.
l.853: Undefined cross reference `Line Layout-pg'. Chapter 2 [5] [6]
Writing index file groff.pg
l.997: Undefined cross reference `Built-in Registers-snt'.
l.997: Undefined cross reference `Built-in Registers-snt'.
l.997: Undefined cross reference `Built-in Registers-pg'. [7]
l.1039: Undefined cross reference `Implementation Differences-snt'.
l.1039: Undefined cross reference `Implementation Differences-snt'.
l.1039: Undefined cross reference `Implementation Differences-pg'.
l.1050: Undefined cross reference `Strings-snt'.
l.1050: Undefined cross reference `Strings-snt'.
l.1050: Undefined cross reference `Strings-pg'.
l.1065: Undefined cross reference `Font Families-snt'.
l.1065: Undefined cross reference `Font Families-snt'.
l.1065: Undefined cross reference `Font Families-pg'. [8]
l.1134: Undefined cross reference `Device and Font Description Files-snt'.
l.1134: Undefined cross reference `Device and Font Description Files-snt'.
l.1134: Undefined cross reference `Device and Font Description Files-pg'.
[9] l.1192: Undefined cross reference `Numeric Expressions-snt'.
l.1192: Undefined cross reference `Numeric Expressions-snt'.
l.1192: Undefined cross reference `Numeric Expressions-pg'.
l.1198: Undefined cross reference `Registers-snt'.
l.1198: Undefined cross reference `Registers-snt'.
l.1198: Undefined cross reference `Registers-pg'. [10]
l.1306: Undefined cross reference `Built-in Registers-snt'.
l.1306: Undefined cross reference `Built-in Registers-snt'.
l.1306: Undefined cross reference `Built-in Registers-pg'.
l.1310: Undefined cross reference `Device and Font Description Files-snt'.
l.1310: Undefined cross reference `Device and Font Description Files-snt'.
l.1310: Undefined cross reference `Device and Font Description Files-pg'.
[11] l.1360: Undefined cross reference `Warnings-snt'.
l.1360: Undefined cross reference `Warnings-snt'.
l.1360: Undefined cross reference `Warnings-pg'.
l.1375: Undefined cross reference `gtroff Output-snt'.
l.1375: Undefined cross reference `gtroff Output-snt'.
l.1375: Undefined cross reference `gtroff Output-pg'. [12]
l.1462: Undefined cross reference `Built-in Registers-snt'.
l.1462: Undefined cross reference `Built-in Registers-snt'.
l.1462: Undefined cross reference `Built-in Registers-pg'.
l.1485: Undefined cross reference `I/O-snt'.
l.1485: Undefined cross reference `I/O-snt'.
l.1485: Undefined cross reference `I/O-pg'. [13]
l.1571: Undefined cross reference `Device and Font Description Files-snt'.
l.1571: Undefined cross reference `Device and Font Description Files-snt'.
l.1571: Undefined cross reference `Device and Font Description Files-pg'.
[14] [15] Chapter 3 [16]
l.1773: Undefined cross reference `GNU troff Reference-snt'.
l.1773: Undefined cross reference `GNU troff Reference-snt'.
l.1773: Undefined cross reference `GNU troff Reference-pg'.
l.1801: Undefined cross reference `Formatter Instructions-snt'.
l.1801: Undefined cross reference `Formatter Instructions-snt'.
l.1801: Undefined cross reference `Formatter Instructions-pg'. [17]
l.1895: Undefined cross reference `Input Conventions-snt'.
l.1895: Undefined cross reference `Input Conventions-snt'.
l.1895: Undefined cross reference `Input Conventions-pg'.
l.1928: Undefined cross reference `Measurements-snt'.
l.1928: Undefined cross reference `Measurements-snt'.
l.1928: Undefined cross reference `Measurements-pg'. [18]
l.1936: Undefined cross reference `Manipulating Spacing-snt'.
l.1936: Undefined cross reference `Manipulating Spacing-snt'.
l.1936: Undefined cross reference `Manipulating Spacing-pg'. [19]
l.2121: Undefined cross reference `Page Layout-snt'.
l.2121: Undefined cross reference `Page Layout-snt'.
l.2121: Undefined cross reference `Page Layout-pg'.
l.2132: Undefined cross reference `Line Layout-snt'.
l.2132: Undefined cross reference `Line Layout-snt'.
l.2132: Undefined cross reference `Line Layout-pg'. [20] [21]
l.2246: Undefined cross reference `Italic Corrections-snt'.
l.2246: Undefined cross reference `Italic Corrections-snt'.
l.2246: Undefined cross reference `Italic Corrections-pg'. Chapter 4 [22]
Writing index file groff.ma
[23] [24] [25] [26] [27]
l.2799: Undefined cross reference `Request Index-snt'.
l.2799: Undefined cross reference `Request Index-snt'.
l.2799: Undefined cross reference `Request Index-pg'.
l.2799: Undefined cross reference `Escape Sequence Index-snt'.
l.2799: Undefined cross reference `Escape Sequence Index-snt'.
l.2799: Undefined cross reference `Escape Sequence Index-pg'. [28]
Writing index file groff.rq
[29]
Writing index file groff.vr
Writing index file groff.st
[30] [31] [32] l.3222: Undefined cross reference `ms Footnotes-snt'.
l.3222: Undefined cross reference `ms Footnotes-snt'.
l.3222: Undefined cross reference `ms Footnotes-pg'. [33] [34] [35] [36]
[37] l.3590: Undefined cross reference `Lists in ms-snt'.
l.3590: Undefined cross reference `Lists in ms-snt'.
l.3590: Undefined cross reference `Lists in ms-pg'. [38] [39]
kpathsea: Running mktextfm lcircle10
/usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source abbreviation 
 for lcircle10.
/usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; 
input lcircle10
This is METAFONT, Version 2.71828182 (TeX Live 2022/Debian) (preloaded base=mf)


kpathsea: Running mktexmf lcircle10
! I can't find file `lcircle10'.
<*> ...our; mag:=1; ; nonstopmode; input lcircle10

Please type another input file name
! Emergency stop.
<*> ...our; mag:=1; ; nonstopmode; input lcircle10

Transcript written on mfput.log.
grep: lcircle10.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; input 
lcircle10' failed to make lcircle10.tfm.
kpathsea: Appending font creation commands to missfont.log.

../../../../../doc/groff.dvi.t2d/doc!groff.t2d/dvi/src/groff.texi:3724: Font @c
ircle=lcircle10 not loadable: Metric (TFM) file not found.
<to be read again>
                   @relax
@cartouchefontdefs ...nt @circle =lcircle10@relax
                                                  @circthick =@fontdimen 8@c...

@\cartouche ...ment @cartouche @cartouchefontdefs
                                                  @ifhmode @par @fi @startsa...
l.3724 @cartouche

?
../../../../../doc/groff.dvi.t2d/doc!groff.t2d/dvi/src/groff.texi:3724: Emergen
cy stop.
<to be read again>
                   @relax
@cartouchefontdefs ...nt @circle =lcircle10@relax
                                                  @circthick =@fontdimen 8@c...

@\cartouche ...ment @cartouche @cartouchefontdefs
                                                  @ifhmode @par @fi @startsa...
l.3724 @cartouche

Output written on groff.dvi (43 pages, 137372 bytes).
Transcript written on groff.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make: *** [Makefile:16786: doc/groff.dvi] Error 1

> 
> Regards,
> Branden
> 
> 
> 
>     _______________________________________________________
> 
> To reply to this notification, you have two options:
> * In the Web UI at <https://savannah.gnu.org/bugs/?66583>.
> * By email, ONLY IF you sign your email with a GPG key registered
>   in your Savannah account AND you include the following line
>   in the reply:
> 
>   {savane: user = 296833; tracker = bugs; item = 66583}
> 
> _______________________________________________
> Message sent via Savannah
> https://savannah.gnu.org/



-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]