[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnulib support
Re: Gnulib support
Mon, 10 Sep 2007 13:40:27 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
Kevin Ryde <address@hidden> writes:
> address@hidden (Ludovic Courtès) writes:
>> Widespread libraries already fixed the problem,
Planned support in GSASL, GnuTLS:
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".
> 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
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
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.