Re: Creating a formula for Homebrew

[dmitrii . pasechnik]

On Thu, Aug 25, 2022 at 11:02:59PM -0500, Paul Eggert wrote:
> On 8/25/22 18:20, dmitrii.pasechnik@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 <gord@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. :-)