Re: Gnulib support

From: ludovic.courtes@laas.fr (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: Gnulib support
Date: Mon, 10 Sep 2007 13:40:27 +0200	[thread overview]
Message-ID: <878x7e92ac.fsf@laas.fr> (raw)
In-Reply-To: <87myw0lk0v.fsf@zip.com.au> (Kevin Ryde's message of "Thu\, 06 Sep 2007 10\:22\:56 +1000")

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