* Gnulib support @ 2007-07-29 15:38 Ludovic Courtès 2007-08-16 0:23 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Ludovic Courtès @ 2007-07-29 15:38 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-07-29 15:38 Gnulib support Ludovic Courtès @ 2007-08-16 0:23 ` Kevin Ryde 2007-08-20 8:07 ` Ludovic Courtès 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2007-08-16 0:23 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-08-16 0:23 ` Kevin Ryde @ 2007-08-20 8:07 ` Ludovic Courtès 2007-08-20 23:59 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Ludovic Courtès @ 2007-08-20 8:07 UTC (permalink / raw) To: Kevin Ryde; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-08-20 8:07 ` Ludovic Courtès @ 2007-08-20 23:59 ` Kevin Ryde 2007-08-21 7:53 ` Ludovic Courtès 2007-08-25 8:44 ` Ludovic Courtès 0 siblings, 2 replies; 10+ messages in thread From: Kevin Ryde @ 2007-08-20 23:59 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-08-20 23:59 ` Kevin Ryde @ 2007-08-21 7:53 ` Ludovic Courtès 2007-08-25 8:44 ` Ludovic Courtès 1 sibling, 0 replies; 10+ messages in thread From: Ludovic Courtès @ 2007-08-21 7:53 UTC (permalink / raw) To: Kevin Ryde; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-08-20 23:59 ` Kevin Ryde 2007-08-21 7:53 ` Ludovic Courtès @ 2007-08-25 8:44 ` Ludovic Courtès 2007-09-04 0:27 ` Kevin Ryde 1 sibling, 1 reply; 10+ messages in thread From: Ludovic Courtès @ 2007-08-25 8:44 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-08-25 8:44 ` Ludovic Courtès @ 2007-09-04 0:27 ` Kevin Ryde 2007-09-04 7:36 ` Ludovic Courtès 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2007-09-04 0:27 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-09-04 0:27 ` Kevin Ryde @ 2007-09-04 7:36 ` Ludovic Courtès 2007-09-06 0:22 ` Kevin Ryde 0 siblings, 1 reply; 10+ messages in thread From: Ludovic Courtès @ 2007-09-04 7:36 UTC (permalink / raw) To: Kevin Ryde; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-09-04 7:36 ` Ludovic Courtès @ 2007-09-06 0:22 ` Kevin Ryde 2007-09-10 11:40 ` Ludovic Courtès 0 siblings, 1 reply; 10+ messages in thread From: Kevin Ryde @ 2007-09-06 0:22 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Gnulib support 2007-09-06 0:22 ` Kevin Ryde @ 2007-09-10 11:40 ` Ludovic Courtès 0 siblings, 0 replies; 10+ messages in thread From: Ludovic Courtès @ 2007-09-10 11:40 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-09-10 11:40 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-29 15:38 Gnulib support Ludovic Courtès 2007-08-16 0:23 ` Kevin Ryde 2007-08-20 8:07 ` Ludovic Courtès 2007-08-20 23:59 ` Kevin Ryde 2007-08-21 7:53 ` Ludovic Courtès 2007-08-25 8:44 ` Ludovic Courtès 2007-09-04 0:27 ` Kevin Ryde 2007-09-04 7:36 ` Ludovic Courtès 2007-09-06 0:22 ` Kevin Ryde 2007-09-10 11:40 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).