Hi, Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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
