Re: Avoid gawkextlib as a separate shared library

[Manuel Collado]

El 17/05/2022 a las 18:43, Andrew J. Schorr escribió:
> On Tue, May 17, 2022 at 08:54:01AM -0600, arnold@skeeve.com wrote:
> > Manuel Collado <mcollado2011@gmail.com> wrote:
> >
> > > IIRC, there have been other people confused about the role of gawkexlib
> > > as a required DLL. ....
> > > [...]
> > > Is it ok to discuss the issue again?
> >
> > I don't object. I think anything that simplifies gawkextlib installation
> > is good.
>
> I don't mind discussing it, but I do mind implementing it. We have a working
> solution that even MinGW libtool handles properly. With what few spare cycles
> I have, I'd rather work on building a front-end installation script than
> reengineering the existing infrastructure.

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?

Regards.

--
Manuel Collado - http://mcollado.z15.es