Follow-up Comment #26, bug #66583 (group groff): At 2024-12-28T16:04:10-0500, anonymous wrote: > Follow-up Comment #23, bug #66583 (group groff): > [comment #21 comment #21:] >>> Follow-up Comment #15, bug #66583 (group groff): >>> 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.
Ah. "Up-to-date" is also a term of art when discussing the operation of
make(1). I don't think of Texinfo 5.0 as "up-to-date"; it's about 12
years old. What it is, is adequate to correctly interpret _groff_'s
Texinfo manual.
> The problem Alex was experiencing, though, occured with a version
> which groff accepted.
Okay, well, he should be getting CCed on this so maybe he can put us in
the picture.
> 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".
Right. I'm aware of that, as it's my own changes to groff's Texinfo
that bumped the dependency up to 5.0 from whatever it was before (I've
forgotten).
> 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.
Correct. It was mandatory. Well, maybe not before Ingo went on an
axe-murdering frenzy in the Byzantine maze that _doc/doc.am_ used to be
(if you think it's bad now...). I don't recall.
If you're curious, here's the commit:
commit 3805d2a0e4aebb84d896f86285fd565488e849bb
Author: Ingo Schwarze <schwa...@openbsd.org>
Date: Tue Apr 12 14:36:12 2022 +0200
>> 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
Automated tests per se are not run automatically. You have to demand
the "check" target of the Makefile for that to happen.
The repository, and the distribution archives, are written with default
make targets selected in the expectation of a relatively unsophisticated
user who hasn't mastered all the parts of the groff system and simply
wants "all the usual stuff". The "usual stuff" avowedly includes
documentation of the system in question. This is standard practice in
Unix software release management and has been for decades.
> or build docs.
> I really dislike this approach of "we're smarter than the user".
In contrast, I really dislike an approach of playing guessing games with
one user who wants to remold groff's build system to adopt his personal
preferences as new defaults.
Why are you riding on the tip of groff's master branch if you're not
interested in whether it works as an integrated whole?
> 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.
An alternative approach that might suit you is to simply stop running
"make" without any arguments. If your area of interest is narrowly
focused, say that. Not (just) to me, but _to the system_. For example,
when I'm in a tight cycle of bashing on the formatter, I'm typically
subjecting it repeatedly to some canned input experiment while I
(sometimes ham-fistedly) revise C++ code. I say "make troff", because
at that point, like you, I don't _care_ whether an integration test is
going to fail. If I can't solve the problem I'm focused on, I throw my
change(s) away. No point risking a regression if I can't resolve the
issue at hand.
Similarly for for "pic", "eqn", and, to name another recent example,
"libgroff.a". These things sit in the root of the build tree,
incongruously with the locations of their source code; my surmise is
that this is the case precisely to facilitate the mode of (partial)
rebuilding in the previous paragraph. I suspect it's an old technique,
predating the ubiquity of shells that would tab-complete file names.
James Clark wrote groff, at least in the early stages, on a SunOS 4
machine. I remember SunOS 4. The default shell was csh. It was a rite
of passage for budding Unix nerds to learn about tcsh and use it
instead.
>> 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.
Just getting a source tree to a point where you could build it
successfully with a high degree of reliability used to be a huge problem
in Unix. Life in the 1980s was hellish in this respect. Automake grew
out of an environment where "./configure && make" was regarded--widely,
but not quite universally--as a major breakthrough.
It took another 1-2 decades for more people to appreciate the virtues of
"bootstrapping" versions of builds, an alternative configuration where
you might build a stripped-down version of your project as a temporary
measure to get some other projects/packages building, and later, in many
cases, return to the first project and do a full build. The plethora of
architectures we once had, which peaked in the early first decade of
2000's, underscored the value of this. Possibly it was around this time
that Automake fell into one of its moribund periods.
> 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).
Or, as noted above, you could just ask `make` for the targets you care
about, instead of elaborating the build system so that you never have to
give that command any arguments.
> 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.
I think that the problem is worked around if you put the implicit "make
all" on the shelf.
>> 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...
Or not making "all"...
>> 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
They've got to go somewhere. You said you were unhappy with your effort
to relocate it.
> and (2) automake conditionals weren't broken.
I'd wager that the Automake developers aren't complete idiots, and that
there is a good reason for them to not govern make(1) targets.
I would characterize my own solution...
diff --git a/doc/doc.am b/doc/doc.am
index 625f9cace..a4f0df6cf 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -542,13 +542,18 @@ endif
#info_TEXINFOS = doc/groff.texi
#doc_groff_TEXINFOS = doc/fdl.texi
+if HAVE_MAKEINFO
+GROFF_INFO = doc/groff.info
+GROFF_TXT = doc/groff.txt
+GROFF_HTML = doc/groff.html
+endif
+
if USE_TEX
GROFF_DVI = doc/groff.dvi
GROFF_PDF = doc/groff.pdf
-endif
+endif # USE_TEX
-all: doc/groff.info doc/groff.txt doc/groff.html \
- $(GROFF_DVI) $(GROFF_PDF)
+all: $(GROFF_INFO) $(GROFF_TXT) $(GROFF_HTML) $(GROFF_DVI) $(GROFF_PDF)
# Distribute the manual in source form as well.
EXTRA_DIST += doc/groff.texi.in doc/groff.texi doc/fdl.texi
...as straightforward, but I dare not say idiomatic.
Having had to deal with cmake, I'm firmly convinced that it lacks
greener grass.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
