Follow-up Comment #21, bug #66583 (group groff): 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).
> 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.
> 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. 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.
> 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. Once upon a time (about 22 years ago),
it was used only by what was then called "doc/homepage.ms" (now
"doc/webpage.ms"), so doc/doc.am (though at that time groff didn't use
Automake) was the correct place to site its management. Then Keith
Marshall started to use it in his "pdfmark.ms" document (since dropped
from groff). Then around 2006, hdtbl examples started using it. Then
when Peter Schaffter contributed mom, or at some point afterward, he
started using it in mom's example documents. Later still, I drafted it
into service as an artifact for automated testing.
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.
> 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). 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.
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".
> To be honest, I am not sure it's the right patch; it's just the one
> that matched my abilities. If anyone is capable of fixing this
> properly, it's Branden, but he doesn't seem very eager to do it.
That's a fair reading. See above.
> 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. 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.
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.
Disabling the rest of the documents, not so much, because as I said they
also serve as integration tests of functional code being shipped.
While we're spewing invective at documentation that insists on being
built, we might remind ourselves that groff, as a typesetting
application, _is a system for creating documentation_.
If you think I take automated testing lightly, I can point you to about
280 exhibits of contrary evidence. If a groff build fails in producing
its documentation, I want to hear from people who observe it; it's not
some corner case or weird syntax exercised by a regression test, but a
class of problem much more likely to be observed in user's documents.
> 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.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
