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

[anonymous]

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

[comment #21 comment #21:]
> At 2024-12-27T19:23:56-0500, anonymous wrote:
>> Follow-up Comment #15, bug #66583 (group groff):
>> 
>> [comment #13 comment #13:]
>>> Alex, does this fix address the problem you reported to the email
>>> list in the "Build error in Devuan stable" thread (linked in comment
>>> #4 and comment #5 here)?
>> 
>> I doubt it will, because in his case, ./configure evaluated makeinfo
>> as present & up-to-date,
> 
> Either I'm confused, or you mean not "makeinfo", but one or more of the
> artifacts that "makeinfo" produces (groff.info, groff.html, and
> groff.txt), the first two of which are only a subset of artifacts
> produced since these formats involve multiple output files).

I meant the program itself; outdated versions of makeinfo are treated as
missing.
The problem Alex was experiencing, though, occured with a version which groff
accepted.

>> and only the subsequent build failed. My patch merely addresses cases
>> where one doesn't have (up-to-date) makeinfo. Note that in the message
>> I linked, I instructed him to manually modify the patch.
>> 
>> I have an expanded version locally which adds flag to ./configure to
>> not build the Texinfo manual even when makeinfo is present &
>> up-to-date.
> 
> Again, either I'm confused or you are.  makeinfo(1) is an external
> program.  We do not declare it as a prerequisite, so make(1) never
> evaluates its up-to-dateness.  If a target requiring the command is run,
> and makeinfo(1) is not found or not executable, the target fails.

Let me quote m4/groff.m4:

# We need makeinfo from Texinfo 5.0 or newer, for @codequoteundirected.
# The minor version checking logic is present for future needs.

...notice the words "or newer".

The following is also false. If makeinfo is not present or is outdated,
./configure used to fail without even allowing make to be run before you
accepted my patch.

>> I haven't posted it yet because I deemed it incomplete. It deals only
>> with the Texinfo manual and not with the rest of the docs, which might
>> also be desired.
> 
> Not by me.

Don't worry, I already noticed that.

> We get some good integration testing out of generating mom's
> documentation and groff-man-pages.{txt,pdf}.  For that matter, ms.ps and
> me{ref,intro}.ps serve as integration tests for the "ms" and "me" macro
> packages.

Fair enough, but sometimes one doesn't want to run tests or build docs.
I really dislike this approach of "we're smarter than the user".
With how spaghetti-like documentation-related build instructions are
in the repo, though, I am not sure I would like the maintenance burden
of such a feature myself. The fact that my patch to allow disabling
building all docs touches 37 files illustrates this well.

>> I had hoped that Branden would assist me in disentangling the gnu.eps
>> file from the rest of documentation, which would allow me to extend
>> this to the entire docs.
> 
> That file plays multiple roles.  [...]
> 
> In any case it needs to be built for inclusion in the distribution
> archive.  We don't have a hard dependency on the pnmtools, which
> generation of "gnu.eps" from "gnu.xpm" requires.

I know it does, the difficulty for me was in disabling the rest of the
docs without affecting gnu.eps. That issue has been solved now.

>> Alas, it seems he doesn't get the desirability of such changes, let
>> alone the idiocy of the current setup, so I am sending the patch to
>> the mailing list in case someone finds it useful.
> 
> I'm not motivated to bend our Automakery into shapes that Automake
> doesn't easily accommodate (not saying--yet--that any patch of yours
> does that).

I will do it on your behalf and say upfront that the way in which autotools
support building manpages clearly shows they never considered them being
built separately or not at all. That is also why these patches are adding
flags to ./configure instead of adding make targets (which would be the
correct approach, but at least an order of magnitude more complicated with
autotools).

> Better alternatives are to solicit the Automake developers
> for the features we need, or, shock horror, have
> builders-from-the-repository install more build dependencies (this is
> already the case anyway, e.g., with bison/yacc) or invite them to grab
> the generated copies of the manual from a distribution archive (which
> they can produce with "make dist").
> 
> Admittedly, the date stamp on groff.texi is going to bump with
> considerable frequency, so make(1) will keep finding the generated
> targets out-of-date and demand TeX/makeinfo again.

I am glad you recognize how impractical this approach is. It's also worth
noting that this previously worked only thanks to a hack in the autoconf
macro that checks the availability of makeinfo.

> Since the people who don't want to build the documentation are also
> unlikely to ever contribute patches to it, perhaps the best solution to
> is to concretely manifest one's contempt for documentation with "git rm
> doc/groff.texi".

...only after obtaining doc/groff.* from elsewhere...

> [...]
> 
>> The problematic part is doc/gnu.eps. The instructions for building it
>> are specified in doc/doc.am alongside other documentation, but the
>> file itself is included by tests as well.
> 
> Well then, it is not something that should be predicated on any
> conditions governed by --no-docs, --without-docs, --screw-the-docs, or
> what have you.

I never said it is.

> It's similarly unwise to delete the line
> 

> include $(top_srcdir)/doc/doc.am


> 
> ...from "Makefile.am", as a documentation-hater might feel tempted to
> do.

It wouldn't be if (1) doc/doc.am didn't contain instructions related to
doc/gnu.eps and (2) automake conditionals weren't broken.

> Let "doc.am" do the work it needs to do to satisfy the rest of the
> build.  If there's a _clean_ way to pass over the generated forms of our
> Texinfo manual in silence, I'm amenable to them.

https://savannah.gnu.org/bugs/?66609 does exactly that. The only issue it
has is that I'm not sure how should manually disabling building the manual
be reflected in the summary of available features that ./configure prints.
The current state is that it prints:

can build groff.{info,html,txt}  : no
can build groff.{dvi,pdf}        : no

as if makeinfo wasn't available. I am not sure whether this is correct
behavior.

> [...]
> 
>> I have tried extracting the instructions related to it into a separate
>> file, but it didn't work correctly. I will try looking into it again
>> and try to make it work.
> 
> I wouldn't bother.  As noted, "gnu.eps" wears several hats, and moving
> the rules for generating it to the top level would.  (I'm annoyed enough
> that "penguin.{ps,pdf}" get produced in the root of the _build_
> directory.)

It's actually not that hard; the hard part was disabling the rest of the
docs. I put it back into doc/doc.am in the end, though, because it didn't
seem like extracting its instructions into doc/gnu.eps.am really improved
anything.


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature