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. > > > > 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.
Here is a gettext bug report addressing this issue, basically. Posted in 2011, no followups. https://lists.gnu.org/archive/html/bug-gettext/2011-10/msg00012.html > > > > 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. > > > > 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"). >