On Thu, Aug 25, 2022 at 11:02:59PM -0500, Paul Eggert wrote: > On 8/25/22 18:20, dmitrii.pasech...@cs.ox.ac.uk wrote: > > > > There has been no official gnulib release in like 8 years... > > As far as I'm concerned none of the releases have been "official". > Gnulib simply doesn't work that way. If you want something that does > work that way, feel free to use Gnulib to build it. However, I expect > you'll find it's more trouble than it's worth; I don't recommend it. > > > > Some people want to follow gnulib guidelines to the letter - even though > > as you admit it's meant mostly for a small range of mostly FSF's > > projects crucially dependent on gnulib, > > I didn't say that. Gnulib can be used elsewhere.
My point is that it's used "elsewhere" not in the way you envision, but by simply committing the code produced by gnulib-tool into the source tree, and forgetting all about it. Basically, planting bugs to be fixed later everywhere. (Cf. the message from a Gentoo contributor in this thread). > > > > For 3+ years we didn't see a bug while using gettext's m4 macros needed > > for iconv support > > This sounds like it's more a gettext issue, so I suggest filing a bug > report there. It's the issue of AM_ICONV being broken, unless one either uses gnulib-tool to seed the project with config.rpath, or getting config.rpath in a right place for automake for some other means. (Does gettext misappropriate prefixes AM_ and AC_ for its macros, making an impression that they are from autotools?) I don't quite understand the relationship between automake, gettext, and gnutools here. Is AM_ICONV even meant to work without gnulib? Or is it a libtool bug? > > It's some kind of a weird tradition of jumping through > > hoops to get config.rpath, while config.guess and config.sub are > > provided by automake. :-) > > Automake (and Gnulib) are actually downstream from the source for > config.guess and config.sub. I don't know about config.rpath. config.rpath (in gnulib) appears to be an orphan. There is no contact address to report bugs in its header. It's only # Copyright 1996-2022 Free Software Foundation, Inc. # Taken from GNU libtool, 2001 # Originally by Gordon Matzigkeit <g...@gnu.ai.mit.edu>, 1996 Is it maintained by libtool, or forked from libtool and maintained by gnulib? > > > > Imagine gnulib was a C macro library, for which you provided a tool to > > copy select sets of headers into the downstream source trees > > I don't have to imagine that, as that's basically what Gnulib is (though > I would drop the word "macro"). Yes, gnulib is ATM a great tool to plant bugs downstream, long-term. :-)