Re: gnulib & modules

[Sam S. <sd...@gn...>]

> * Daniel Jour <qnavry.bregjvt@tznvy.pbz> [2016-08-31 13:57:12 +0200]:
>
>> This is why we don't run gnulib-tool in that directory!
>> We only ever run it in src.
>
> Hm, I'm afraid that this not a good idea, at least not a scalable
> one. Let me explain: We have modules because we don't want to have
> their code in core CLISP, and we want to be able to (or let the user)
> provide modules to extend CLISP at will (and even at runtime, with
> dynamic loading).

The rule above is only for _base_ modules.
http://clisp.org/impnotes/modules.html#base-modules
These are the modules that are always available to the user.

> And adding a new module should not require changes to core CLISP,
> right? A user should be able to write some module, and let clisp-link
> from the installed CLISP do it's magic.

Yes, other modules (e.g., rawsock & pcre) should have their own gnulib
shared libraries - but not the code.

> Now assume a CLISP module needs (for example) access to some_function,
> but core CLISP does not. The gnulib module the_module provides that
> some_function on systems where it's not available. Should we add
> the_module to core CLISP? I think no, because that would bloat core
> CLISP (and we'd need special linker flags to actually have it in the
> resulting binary). Thus we add it to the CLISP module, and
> everything's fine.

Right.
Note that "core CLISP" is actually the base linkset, not the boot
linkset.

Also, the pernicious nature of gnulib is the dependency creep.
IOW, if you want to use gnulib_module_1, chances are that it will also
pull gnulib_module_2, gnulib_module_3, gnulib_module_4 &c.
And if some of these modules are already present in the base clisp, we
do not want the module to pull it in.

> My point is: gnulib is not designed to be something "shareable" across
> projects (and core CLISP and a module is basically that: two separate
> projects).

This sucks.

> Thus IMO the correct approach at using gnulib is to have a gnulib
> checkout for core CLISP, using only the gnulib modules needed by core
> CLISP. And letting each CLISP module (which wants/needs to use gnulib)
> maintain an own gnulib checkout with only the gnulib modules needed by
> that particular CLISP module.

Indeed this is an easy way.

> This adds some bloat when functionality overlaps (rawsock and
> socket.d, and basic stuff like file IO), but probably only on "gnulib
> intensive" platforms (windows?):
> https://sourceforge.net/p/clisp/bugs/634/

The dependency creep of gnulib means that on any non-glibc platform it
is often a copy of a large part of glibc.
Even on linux - on LINUX, Carl! - it pulls in ioctl!

> Also I think complaining about a missing libgnu.so won't help. That's
> just not the way gnulib is supposed to be used.

This sucks double.

However, I tried to fight this battle 5 years ago and I am not
interested in re-fighting it now.
If every non-base module gets a 1MB libgnu.a, I guess our users will
have to live with it.

Bruno, is this really the way to go?

>> what was the problem [updating gnulib for core CLISP]?
>
> I'm not entierly sure. Makefile.devel tried to update (?) something
> (configure?) for all modules first, but this failed for all
> modules. IMO updating gnulib should - in the end - be no more effort
> than running gnulib-tool --update (in the correct directories, that is
> the top level directory and every module directory that has an own
> gnulib checkout, we could put that into a script or Makefile.devel
> then).

That's what the gnulib-imported target does, more or less.


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1404
http://www.childpsy.net/ http://jihadwatch.org http://islamexposedonline.com
http://truepeace.org http://mideasttruth.com http://americancensorship.org
To iterate is human; to recurse, divine.