Re: [PATCH] Install new autoreconf files.

Oswald Buddenhagen via Mutt-dev wrote in
 <[email protected]>:
 |On Mon, Apr 13, 2026 at 06:21:22PM +0800, Kevin J. McCarthy wrote:
 |>https://www.gnu.org/software/gettext/manual/html_node/Distributed-Develo\
 |>pment.html
 |>
 |>However, if it I did something wrong, then let's talk about what needs 
 |>to be changed.
 |>
 |it's not wrong per se. it's more of a philosophy thing, whether you want 
 |to do pure source control, or want to veer toward configuration 
 |management. at the extreme end, you would be committing binaries for 
 |every supported platform for each release. i'm a source control purist, 
 |and would therefore delete (and gitignore) every file that is somehow 
 |generated by/from something else in the repo.

It has come to that.  But traditionally -- as i perceive(d) it --
projects were buildable and installable out of the box.
They also had readily usable Unix manual pages, regardless of how
these were managed on the source level.

Some of the programs i "track" and use are still of the
traditional sort, but it is getting rare; lynx, mawk, bash, dtach,
zlib.  Several Makefile-only projects like nawk, lua, dnsmasq.

For example, i yesterday had (wanted) to build lighttpd on
AlpineLinux, and it has the build-base meta package installed.  So
i tried, and i had to go via several tries (automake, autoconf,
libtool, plus some lib -dev's) to be able to autogen.sh.
Then quickly rid of all that, which luckily worked pretty smoothly
thanks to apk.

Heck, sometimes terrifying things have to be installed in order to
get things going (take rdfind dependency for Linux firmware, rsync
for the Linux kernel, not to talk about what is needed for
building manuals, like "ronn" for ipcalc, and that i really reject
to do).

Also sometimes i look at ArchLinux package recipes, now less than
a few years ago, but the build/runtime dependencies really get
through the roof, in my opinion.
I mean it is .. so .. but if you are building yourself, it slowly
stops making fun.  Look how many private libraries FreeBSD now
ships, for example.  If i would not have overlays i would now even
need Rust (glycin <- gdk-pixbuf) and Go (to workaround new
impossibility to use fakeroot here since package system now
completely statically linked via upstream).

Mesa for example now requires yaml plus python3 yaml stuff only to
convert several pretty simple files that formerly were in a format
directly usable by "the machine" (if i got that right), and it
gained several more such dependencies through drivers i need.
Unfortunately i need Mesa as other programs depend.
Anyhow, you end up with an ever growing system of dependencies
noone whatsoever can or wants to penetrate.

I am really happy btrfs-progs now ships with readily prepared
manuals.  The system here simply did not install them anymore;
likewise qemu, imagine this big big thing; at first the lead
developer built it locally, and included that as a .XZ ball, but
since 2023-09-23 we have to live without them.

In short.  I personally *love* to simply check something out, and
be able to build and install, and that includes manual pages.
I (still personally) can absolutely understand the desire to have
easy usable abstractions when developing, but including a readily
prepared set, at least at times, or on a dedicated branch, even if
that is rebased / re-build-up frequently, or whatever, you know?

And like this one can at least be sure that a/the developer has
had an overview / trial at "that [bullshit] mountain" once, or so.

 ...
 |if there actually are any version dependencies between gettext and the 
 |surrounding autoconf infra, one can code a constraint into configure.ac.  
 |that would be a problem for people building from git with mismatched 
 |versions who somehow still want to build translations. i wouldn't feel 
 |constrained by this hypothetical user group.

gettext is a monster.  Our packager team does

        --enable-{shared,static} \
        --disable-{csharp,java,nls} \
        --without-{emacs,git} \
        --with-included-{glib,libcroco,libxml,libunistring}

but it seems to me it is still pretty huge for a dictionary lookup
that uses unfortunately non-standardized ({..}) code injections
for caching purposes.  (If it is done like that.)

 --End of <[email protected]>

Ah people sorry for the noise, i jabber on lists i am doing
nothing for.
But mutt .., happy 30th anniversary this year!  And i used it
i think already pre Y2K (a bit)!
Congratulations everyone.  (Now silent.)

Ciao

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)