Gnulib support

Gnulib support

[Ludovic Courtès]

Hi,

I just committed Gnulib support in HEAD.  In the long run, this can be
an appreciable portability aid, provided we make good use of the
available modules.  Currently, the only imported modules are `alloca'
and `strcasecmp' (see `m4/gnulib-cache.m4').  Other modules would
certainly be useful.

Note that only LGPL modules are imported.  Furthermore, the Gnulib folks
guarantee that whatever LGPL variant we end up using, they will arrange
so that the modules we need are licence-compatible with libguile [0,1].

In practice, one must now run `gnulib-tool --update' before running
`autoreconf' (`autogen.sh' was updated to do that).  The only file that
needs to be kept in the repository is `m4/gnulib-cache.m4' since other
files are automatically fetched by `gnulib-tool'.

Note that you'll probably need to run "make distclean" before doing
anything the first time you update.

Let me know of any problems you encounter or any comments that you have.

Thanks!

Ludovic.

[0] http://article.gmane.org/gmane.comp.lib.gnulib.bugs/10913
[1] http://article.gmane.org/gmane.comp.lib.gnulib.bugs/10914



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Kevin Ryde]

ludo@gnu.org (Ludovic Courtès) writes:
>
> Currently, the only imported modules are `alloca' and `strcasecmp'
> (see `m4/gnulib-cache.m4').

What prefix does it put on the names that get into libguile.so?
It's not namespace clean to have an strcasecmp() in libguile (likely
to create subtle havoc).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> What prefix does it put on the names that get into libguile.so?
> It's not namespace clean to have an strcasecmp() in libguile (likely
> to create subtle havoc).

In the case of `strcasecmp ()', it puts no prefix.  However, the
`strcasecmp' module gets compiled iff `strcasecmp' was not found at
configure time.  If we find a situation where this goes wrong, then we
should email `bug-gnulib'.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> However, the `strcasecmp' module gets compiled iff `strcasecmp' was
> not found at configure time.

The problem is if other libraries do the same thing, ie. put an
strcasecmp in.  I expect you get clashes that'd stop an application
using certain combinations of libraries, or getting mis-detections of
what's available where, etc.

For namespace cleanliness any globally visible symbol in libguile really
has to have an scm_ (or probably scm_i_) prefix.  Is gnulib setup to
help libraries with that?  Nosing around it looks like perhaps not yet.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> For namespace cleanliness any globally visible symbol in libguile really
> has to have an scm_ (or probably scm_i_) prefix.  Is gnulib setup to
> help libraries with that?  Nosing around it looks like perhaps not yet.

Not yet AFAICS.  I'll email `bug-gnulib' about it (if you don't).

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> The problem is if other libraries do the same thing, ie. put an
> strcasecmp in.  I expect you get clashes that'd stop an application
> using certain combinations of libraries, or getting mis-detections of
> what's available where, etc.
>
> For namespace cleanliness any globally visible symbol in libguile really
> has to have an scm_ (or probably scm_i_) prefix.  Is gnulib setup to
> help libraries with that?  Nosing around it looks like perhaps not yet.

Bruno Haible listed potential issues and workarounds in:

  http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11101

(Gmane's threading seems to be slightly broken currently.)

I have not taken any action yet but what you suggest is doable.

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Kevin Ryde]

ludo@gnu.org (Ludovic Courtès) writes:
>
> I have not taken any action yet but what you suggest is doable.

Revert it for now, and look again if/when there's a system for
libraries.  (And not the first blush version of something, give it a
chance for someone else to be the guinea pigs.)


While you're at it you can back out "build-aux".  Subdirs like that are
unnecessary, especially now that it's normal not to copy aclocal .m4
files into a distribution.  (If gnulib is doing that then it shouldn't.)

Oh, and don't mangle the news file just because automake is broken.  The
licence notice should be at the start of the file.  You can setup to
demand a new enough automake if that helps though (on the general
principle that there's no virtue in old build tools).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Ludovic Courtès]

Hi Kevin,

Kevin Ryde <user42@zip.com.au> writes:

> Revert it for now, and look again if/when there's a system for
> libraries.  (And not the first blush version of something, give it a
> chance for someone else to be the guinea pigs.)

Please, do read the thread on `bug-gnulib'.  Widespread libraries
already fixed the problem, the most straightforward solution being to
use Libtool's `-export-symbols-regex' link option (which is a single
line in `Makefile.am').

Did you actually hit a problem?

Honestly, I'd prefer not to revert it (remember it's only in HEAD) if
the rationale is "we're too lazy to fix it".

> While you're at it you can back out "build-aux".  Subdirs like that are
> unnecessary, especially now that it's normal not to copy aclocal .m4
> files into a distribution.  (If gnulib is doing that then it shouldn't.)

And while we're at it, I suggest that we do "mv libguile/*.[ch] .".
Subdirs like that are unnecessary, too.  :-)

Please, provide a more compelling rationale.  Did you find a bug or
something?  I don't see the point in having all files mixed up.

This is unrelated to Gnulib, BTW.

> Oh, and don't mangle the news file just because automake is broken.  The
> licence notice should be at the start of the file.

Hmm, I did not move the licence in `NEWS', though I did remove a few
lines from there [0].  Is this what you are referring to?

Thanks,
Ludovic.

[0] http://repo.or.cz/w/guile.git?a=commitdiff;h=42e184455d0b7a99e231269a5454c1de481ba548


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Please, do read the thread on `bug-gnulib'.

I did.

> Widespread libraries already fixed the problem,

No.

> the most straightforward solution being to
> use Libtool's `-export-symbols-regex' link option (which is a single
> line in `Makefile.am').

Alas doesn't help the static ".a".  You'll also notice in the libtool
manual the caution "no effect on some platforms".

> Did you actually hit a problem?

Neither you nor I will hit a problem.  The systems hurt are ones noone
here hardly ever has to use, which is why it's essential to be very
careful about supposed "help".

It's a great shame really the gnulib bits are being done as yet more
code plonked into every package, to be updated in every package for
every new non-standard system, etc.  The quantity of autoconf, automake,
libtool, gettext, etc already dedicated to egregiously non-free systems
is pretty sad.  If only someone would "bit the bullet" and make a gnulib
or gnuification scheme that brought all those systems (those anyone
cares enough about) up to a gnu level in one hit. :(

> And while we're at it, I suggest that we do "mv libguile/*.[ch] .".
> Subdirs like that are unnecessary, too.  :-)

Don't move stuff about for no reason.  I've asked you before please not
to do things like that just because you feel like it.  It's not year
zero, and there's not enough manpower for actual fixes let alone notice
unintendend consequences of supposed cosmetic changes.  Hiding the build
tools in a subdir is pointless, its only effect is to obscure the
machinery, invalidate a paragraph in the INSTALL file, and give a nice
chance of breaking bits in the tree that assume things are where they
always have been.

> Hmm, I did not move the licence in `NEWS', though I did remove a few
> lines from there [0].  Is this what you are referring to?

The "dist-hook" rule is the best place to make dist-time consistency
checks.  A grep there can do what "check-news" does, but without having
to mangle the file, and indeed with a tighter regexp pattern to suit the
actual format used.  Assuming this is something really wanted at all --
since it should be clear dist restrictions must be made sparingly or
they're just pains in the proverbial.

The sole dist check I've found any good has been looking for "fuzzy"s in
po files, since gettext frequently makes extremely poor guesses at new
message translations.  On the other hand an example of a check that's
too agressive for a dist restriction is demanding all files modified
this year should have this year in the copyright line.  Worth grepping
from time to time, but too easy to get a false miss.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Gnulib support

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

>> Widespread libraries already fixed the problem,
>
> No.

libgettext: http://article.gmane.org/gmane.comp.lib.gnulib.bugs/11101
libprelude: http://article.gmane.org/gmane.comp.lib.gnulib.bugs/11140

Planned support in GSASL, GnuTLS:
http://lists.gnu.org/archive/html/bug-gnulib/2007-08/msg00166.html .

Guile is not the only C library of the GNU Project.  Other people do
have the same problems as we have, and what solutions they implement is
certainly worth considering.

>> the most straightforward solution being to
>> use Libtool's `-export-symbols-regex' link option (which is a single
>> line in `Makefile.am').
>
> Alas doesn't help the static ".a".  You'll also notice in the libtool
> manual the caution "no effect on some platforms".

Agreed.

> It's a great shame really the gnulib bits are being done as yet more
> code plonked into every package [...] If only someone would "bit the
> bullet" and make a gnulib or gnuification scheme that brought all
> those systems (those anyone cares enough about) up to a gnu level in
> one hit. :(

From Gnulib's web page:

  Gnulib is a central location for common GNU code, intended to be
  shared among GNU packages. GCC has libiberty, but this is hard to
  disentangle from the GCC build tree. libit proved too hard to keep up
  to date, and at this point is moribund.

  Gnulib takes a different approach. Its components are intended to be
  shared at the source level, rather than being a library that gets
  built, installed, and linked against. Thus, there is no distribution
  tarball; the idea is to copy files from Gnulib into your own source
  tree.

Personally, I think it solves portability issues pretty well since it
can almost let us program as if we were on a GNU system, without having
to implement loads of ad hoc, bug-ridden workarounds when other people
already solved the same problems better (packages like Coreutils are
ported to a wider range of platforms than Guile.)

However, discussing the Gnulib rationale is off-topic.  Please email the
GNU and Gnulib folks if you know of a better solution.

> Hiding the build tools in a subdir is pointless

I strongly disagree.

At any rate, we have to reach a consensus.  I'd agree to revert it in
1.8 if deemed appropriate (what do others think?), so that it fulfills
the principle of not making "gratuitous cosmetic changes" in the stable
branch (again, what changes qualify as "gratuitous" or "cosmetic" is
debatable).  Would it be OK for you?

> The "dist-hook" rule is the best place to make dist-time consistency
> checks.

We're not alone: Automake folks deemed it better to provide support for
this functionality rather than have all packages implement their own
stuff.  Revert the offending change if you feel like doing it.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel