Follow-up Comment #33, bug #66583 (group groff): Hi Alex,
To lead with a summary: I partly disagree with your rants, but think you
may have identified a bug--the groff developers need to be able to
reproduce it, though. And I can't.
At 2024-12-29T16:14:22+0100, Alejandro Colomar wrote:
> ./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.
I disagree. The purpose of a "configure" script is to probe the system
for properties upon which a source code projects depends to build (or
which it can fruitfully and optionally exercise).
I can't find it right now, but someone once wrote a lengthy article, or
a chapter of a book, on why the X Window System's approach (xmkmf/imake)
to self-configuration of a project's source tree was so terrible
compared to Autoconf.
As I recall, the two most salient points were these:
1. You, the person building the source code of whatever project,
declared to this build system a platform identifier analogous to a
GNU target triple. A master data file inside the xmkmf/imake build
system stored lists of properties describing what was believed to be
true about the targets it knew about. This sucked because X11
didn't have a fast release cycle and, while it was under active
development, new Unix systems (and new releases of existing ones)
were coming out all the time. So xmkmf/imake perpetually lagged
reality, and people constantly deployed it in environments it knew
nothing about.
2. The target-specific list of properties tended to be based on what
the OS vendor _claimed_ about their system rather than empirical
facts. Then, as now, for marketing and other reasons, OS vendors,
particularly in the commercial sector, obfuscate, dissemble, or make
outright fraudulent claims about what features their product
possesses or which bugs it has resolved. This sucked (and still
does) for obvious reasons. As in science, the only way to know for
sure what your build host supports is to empirically test it.
> 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.
That _is_ guessing what you want to do. But "all the usual stuff" is a
good guess. That's what a default make target is _for_.
> 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.
I agree with all this but it's not obvious to me how _groff_ is failing
to adhere to the principle you're espousing.
> Oh, dear, I haven't yet said what I want. Let me try.
>
> 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.
Sure, yes...again, not seeing where _groff_ is failing here.
> 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.
Yes. Sounds good.
> 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.
No, WTF. This...
> prog: prog.c prog.info ## broken dependency list
...should not be the case. Where are you seeing this?
>> 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 broadly agree. _If_ the targets have diligently listed their
prerequisites--nothing missing, nothing superfluous--`make -k` will
build everything that can be reasonably constructed, and nothing that
can't be.
People throwing increasing numbers of parallel cores at the _groff_
build in recent years have exposed missing prerequisite declarations.
I've fixed these as soon as they were brought to my attention. Colin
Watson has backported at least one such fix to the groff 1.23.0 packages
in Debian trixie.
https://salsa.debian.org/debian/groff/-/commit/7f1b2d716c23c3cfeaf24911f7f5184dca6bbf46
>> 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'm not going to put the Autoconf or Automake developers on a pedestal;
I think Thomas Dickey's complaints of about 20 years ago about Autoconf
illustrate how Akim Demaille in particular thickly manured the field for
an Astroturfed rebellion against Autoconf; it didn't take long for
Silicon Valley firms to smell an opportunity to annex territory to their
walled gardens while opening another front in the war against copyleft
and end-user control of computing systems, and plenty of clueless people
who struggle even to type "./configure && make" happily repeated public
relations communiqués touting the superiority of the latest alternative
to the Autotools.
https://invisible-island.net/autoconf/autoconf.html
A regrettable own-goal to have had such feeble release QA procedures.
But, let's not kid ourselves. Silly Valley would have done the same
thing if Autoconf releases had been anything less than bulletproof. And
maybe even then. AL/EPL/MPL/CDDL--stand tall and fight the GNU mind
virus! Here, drink this and don't ask us where it came from. Pay no
attention to the choice-of-law provision (we'll be suing you from
Matthew Kacsmaryk's federal district court if it pleases us, heh heh
heh).[1] I wonder how many FAANG executives had Monsanto on their CVs.
>> I would characterize my own solution...
[snip]
>> +all: $(GROFF_INFO) $(GROFF_TXT) $(GROFF_HTML) $(GROFF_DVI) $(GROFF_PDF)
[snip]
>> ...as straightforward, but I dare not say idiomatic.
> This patch is bad. IMO.
What about it is bad?
> (So was the other, though.) The only proper patch, is one that
> removes the dependency that the binary has on the docuentation.
Note, then, what my patch is doing, or more precisely the fact upon
which it builds. The reason the generated forms of _groff_'s Texinfo
manual are added to the "all" target is _precisely because they are leaf
nodes_ in _make_(1)'s dependency graph! If we deleted this "all:" line,
the documentation _won't get built_.
Here, let me show you my Git working copy with a lengthy, drastic
change:
diff --git a/doc/doc.am b/doc/doc.am
index a4f0df6cf..ee297dc98 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -553,7 +553,7 @@ GROFF_DVI = doc/groff.dvi
GROFF_PDF = doc/groff.pdf
endif # USE_TEX
-all: $(GROFF_INFO) $(GROFF_TXT) $(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
I then _distclean_ed and rebuilt. The build finished with status 0.
What's in my _build/doc_ directory?
$ ls -1 build/doc
GMPfront.t
automake.pdf
gnu.eps
grnexmpl.ps
groff-man-pages.pdf
groff-man-pages.utf8.txt
img
meintro.me
meintro.ps
meintro_fr.me
meintro_fr.ps
meref.me
meref.ps
ms.ps
pic-1.html
pic-10.html
pic-11.html
pic-12.html
pic-13.html
pic-14.html
pic-15.html
pic-16.html
pic-17.html
pic-18.html
pic-19.html
pic-2.html
pic-20.html
pic-21.html
pic-22.html
pic-23.html
pic-3.html
pic-4.html
pic-5.html
pic-6.html
pic-7.html
pic-8.html
pic-9.html
pic.html
pic.ps
webpage-1.html
webpage-10.html
webpage-11.html
webpage-12.html
webpage-13.html
webpage-14.html
webpage-15.html
webpage-16.html
webpage-17.html
webpage-2.html
webpage-3.html
webpage-4.html
webpage-5.html
webpage-6.html
webpage-7.html
webpage-8.html
webpage-9.html
webpage.html
webpage.ps
No _groff.info_. No _groff.txt_. No _groff.html_. No _groff.dvi_. No
_groff.pdf_.
So, kindly, I'd sort of like to know what you guys are hollering about
when you claim groff's Texinfo manual is being crammed down your
throats.
[1] I think onf may not be American, and I know Alex isn't, so here's a
supporting reference.
https://harvardlawreview.org/print/vol-137/district-court-reform-nationwide-injunctions/
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
