Follow-up Comment #28, bug #66583 (group groff): It seems Alex's message didn't make it here; I quote it below verbatim.
Date: Sun, 29 Dec 2024 16:14:22 +0100
From: Alejandro Colomar <a...@kernel.org>
Subject: Re: [bug #66583] [PATCH] allow building groff without makeinfo
Hi Branden,
On Sun, Dec 29, 2024 at 07:53:34AM -0500, G. Branden Robinson wrote:
>> 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.
[...]
> 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.
[...]
> 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.
<rant>
=2E/configure && make is a horrible thing that can only be justified
because computers were slower back then, and because GNU make maybe
wasn't as portable as it is today.
Commands should do one thing and do it well. Those two commands do half
a thing and don't even do it well.
</rant>
Now let's try to document my problem, as you suggested me to do:
<rant2>
A build system shouldn't ****ing try to guess what I want to do. A
build system should build "all the usual stuff" always.
If my system is broken and can't build "all the usual stuff", I want the
build system to fail. Silently not building that part is just broken
behavior usually seen in autotools-using software. The excuse given by
autotools people is that users usually don't know or even care about
those problems and don't know how to solve them. My opinion is that
it should be easy to copy that error message and report it to someone
who knows; if the software just silently stops building a part, then the
user might think that that's all that should be built, and don't even
realize about the problem.
</rant2>
Oh, dear, I haven't yet said what I want. Let me try.
<rant3>
I want the build system to try to build "all the usual stuff". make(1)
provides me with a -k flag, which allows me to continue building stuff
even if part of the build fails. Let me handle the build errors how I
want to handle them. Don't instruct the build system to guess what I
want on error. Just build blindly, and I will use `make -k`, or
`make -i`, or just `make`, depending on what *I* want.
</rant3
And here comes groff's bug:
I expect a makefile of some project which has a binary and docs to be
roughly like this:
all: prog.info prog;
prog: prog.c
cc -o $@ $<
prog.info: prog.texi ## or whatever is the texinfo way
something <$< >$@
That way, if make(1) fails to build prog.info, I can run `make -k` to
continue building the binary, which doesn't depend on the docs.
However, it seems groff's build system is more like this:
all: prog.info prog;
prog: prog.c prog.info ## broken dependency list
cc -o $@ $<
prog.info: prog.texi ## or whatever is the texinfo way
something <$< >$@
Which results in being impossible to run `make -k` to get the binary.
> 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.
No. `make -k` should be a reasonable way to build everything that
doesn't fail, without having to know the names of the specific targets.
If that doesn't work, it's because either you or autotools has done
something very badly.
> 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'm sorry about the rants, and I agree they're not complete idiots, but
they make it very painful to build projects using their software.
>
> 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 =3D doc/groff.texi
> #doc_groff_TEXINFOS =3D doc/fdl.texi
>
> +if HAVE_MAKEINFO
> +GROFF_INFO =3D doc/groff.info
> +GROFF_TXT =3D doc/groff.txt
> +GROFF_HTML =3D doc/groff.html
> +endif
> +
> if USE_TEX
> GROFF_DVI =3D doc/groff.dvi
> GROFF_PDF =3D 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 +=3D doc/groff.texi.in doc/groff.texi doc/fdl.texi
>
>
> ...as straightforward, but I dare not say idiomatic.
This patch is bad. IMO. (So was the other, though.) The only proper
patch, is one that removes the dependency that the binary has on the
docuentation.
> Having had to deal with cmake, I'm firmly convinced that it lacks
> greener grass.
Agree. The only greener grass, I've seen it in pure hand-written
GNUMakefile files. They aren't trivial to write, but they work so well
that it's worth it.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
