Re: Extension packaging

[Andrew J. Schorr]

On Tue, May 10, 2022 at 08:21:10PM +0300, Eli Zaretskii wrote:
> What is the difference between end users and developers, in this
> regard?

Developers are presumably familiar with configure scripts and the
various options.

> 
> > The existing tarballs
> > use standard autotools stuff and typical configure scripts. I have
> > not hacked them to auto-detect the gawk location. The point of a
> > gawkext installation script would be to add that type of intelligence.
> > For a developer, it would not necessarily be a plus for the configure
> > script to start making guesses about where to install things.  A developer
> > might be testing with multiple versions of gawk, for example.
> 
> If you envision the need to install in a non-standard directory, you
> can provide a configure-time switch for that, and leave the default at
> what makes sense for users.  I think.

I hear what you're saying, but I think you're blowing up this issue a
bit. Gawk already has the AWKLIBPATH mechanism for searching a set of
directories for extensions. I think the default "make install" sticks
the libraries in /usr/local/lib/gawk. That's not a terrible place to put
them. It's not completely obvious to me that I'd prefer them somewhere
else, but yes, I recognize that it might be nice to assume that they should
go in the standard location baked into the gawk binary.

I've got limited time to spend on this, and if I do invest any time
in improving installation, I think it's not best spent on patching
configure scripts but rather on building a frontend tool to do
everything automagically.

To be clear, we previously envisioned that various distributions might
start packaging the extensions. On Fedora, you can simply run
"dnf install gawk-json", and it does the right thing. Each extension contains
a "packaging" subdirectory with an RPM spec file that installs
the files in Fedora-standard locations.

Now we're talking about going in a different direction to build our own
install tool. That tool will handle these issues. I don't think each
package's configure script needs to do it, but I recognize that you have
a different and perfectly valid opinion.

Regards,
Andy