Re: Avoid gawkextlib as a separate shared library

[Andrew J. Schorr]

Hi,

On Wed, May 18, 2022 at 11:11:13AM +0200, Manuel Collado wrote:
> Ok. Please let's do a bit of discussion. Just to clarify ideas.
> 
> My point is to simplify building gawkextlib extensions from source
> distribution tarballs. If they need libgawkextlib-0.dll. Possible
> alternatives:
> 
> (1) An installer script or package manager/builder that takes care
> of dependencies. Please consider that a MinGW version is also
> necessary.
> 
> (2) Include /lib in the tarball of every extension that depends on
> it. Let 'make' build both the extensions and the gawkextlib base
> library. Let 'make install' copy gawkextlib files only if not
> already installed. Or better, check the version of the already
> installed ones and overwrite them if older.
> 
> (3) Consider varinit.c and the related macros in gawkextlib.h as an
> enhancement of the gawk extension API. Move those pieces to the gawk
> core. Handle strhash.c as any other source file required by a given
> extension.
> 
> (4) Handle the /lib stuff as regular source files required by
> specific extensions, and link the objects statically. My original
> suggestion.
> 
> Does any of those alternatives make sense? How can they compare
> w.r.t. the effort required to implement?

It's difficult to discuss this sensibly without understanding the current
challenges of MinGW installation. Eli says that libtool works correctly with
the current setup, whereas you say that you had to copy libgawkextlib-0.dll
to a different spot to get things to work. Is it possible to sort out this
issue before discussing what needs to be changed to support MinGW better?

I don't think #3 is going to happen. I'm already planning to work on #1.
I'm just not clear on why #2 or #4 is needed if the current solution works OK.
As far as I know, you are the only one who is having troubles with the
current approach.

Regards,
Andy