Re: Updating a package's gnulib files in CVS
On Nov 26, 2007 10:55 AM, James Youngman [EMAIL PROTECTED] wrote: Essentially it checks gnulib out using cvs checkout -D to get a reproducible version and then imports the indicated modules. The config file and the script which reads it are checked into CVS and included in findutils releases. Eric Blake just told me that in fact git-cvspserver silently does not support update -D and so this technique actually does the wrong thing. I guess findutils will need to move to obtaining the current gnulib via git. It's slightly disappointing that this introduces an extra dependency on git for people checking the findutils code out of CVS. Details at http://savannah.gnu.org/bugs/index.php?21568 James.
Re: Updating a package's gnulib files in CVS
James Youngman [EMAIL PROTECTED] wrote: On Nov 26, 2007 10:55 AM, James Youngman [EMAIL PROTECTED] wrote: Essentially it checks gnulib out using cvs checkout -D to get a reproducible version and then imports the indicated modules. The config file and the script which reads it are checked into CVS and included in findutils releases. Eric Blake just told me that in fact git-cvspserver silently does not support update -D and so this technique actually does the wrong thing. I guess findutils will need to move to obtaining the current gnulib via git. It's slightly disappointing that this introduces an extra dependency on git for people checking the findutils code out of CVS. Details at http://savannah.gnu.org/bugs/index.php?21568 Hi James, I'm feel about CVS the way I've felt about KR C for years now. It's worth supporting if doing so is really easy (i.e., automatic), but when it starts to require too much extra work, then I leave it behind. If you're interested in switching findutils to git -- or even just mirroring cvs-to-git for starters, let me know and I'll set it up. Jim
Re: Troubles with dispose function on oset
Hi, I have written my dispose function, I get as parameter a void pointer, which it seems I must free too. However its prototype is like: typedef void (*gl_setelement_dispose_fn) (const void *elt); Then, if I declare my function with a non-const type as first argument, it will warn me by conflict at prototype. On the other hand, I declare it as const. It warn me if I try to do free() on it. The elements have a type of 'const void *' because the ordered-set implementation does not need write access to the memory pointed to by the pointers. But here, in the dispose function, you need write access. So you need to cast from 'const void *' to 'void *' inside your dispose function. The cast is valid because you guarantee that you have allocated each element with malloc(), realloc(), or calloc(). (In C++, one would have used a template with a type parameter that would be either 'const foo *' or 'foo *'. But this here is C, not C++.) Bruno
Re: Patch for the getpagesize module
Hello Martin, Thanks for your patch. - Don't provide a getpagesize.h header. Modify gnulibs unistd.h instead. Yes, I agree this is useful, because although POSIX does not specify getpagesize() any more, SUSV2 had it declared in unistd.h [1]. - Provide a getpagesize function (not a macro) if the system does not have one. What is the point of doing that? A function that in most cases just returns a fixed number can well be inlined. And since 'inline' is a bit tricky to use portably, we chose to implement it as a macro. What drawbacks do you see with that? Bruno [1] http://www.opengroup.org/onlinepubs/007908775/xsh/getpagesize.html
Re: Patch for the getpagesize module
Martin Lambers wrote: If a macro is used instead, should its definition go into lib/unistd.h.in directly, or should it stay in a separate lib/getpagesize.h, which is then included in lib/unistd.h.in? It should go into lib/unistd.in.h. You can use blank lines or other kinds of separator lines or headlines in comments, to separate it from the other contents of unistd.in.h. I also was not sure if it's okay to include additional system headers like OS.h in the middle of gnulibs unistd.h. Good point; this brings a certain amount of namespace pollution. Nevertheless, I'd try first to continue using a macro, and include OS.h from unistd.h, and switch to a function instead only when we see that it's needed. Bruno
Re: test-xprintf-posix.sh failure on NetBSD 1.6
Jim Meyering [EMAIL PROTECTED] wrote: I've just run the test-xprintf-posix.sh test on NetBSD 1.6 and saw this failure: ... make[3]: Leaving directory `/tmp/coreutils-6.9.89.12-8e412/gnulib-tests' make check-TESTS make[3]: Entering directory `/tmp/coreutils-6.9.89.12-8e412/gnulib-tests' 4,19c4,7 0x0p+0 33 inf 33 -inf 33 inf 33 12.75 33 1234567.00 33 -0.031250 33 0.00 33 1234.00 33 1234 33 12.75 33 1234567.00 33 -0.031250 33 0.00 33 1234.00 33 1234 33 --- a 0 a 0 a 0 0a 0 31a20,31 1.27500 33 1.23457 33 -3.12500 33 0.0 33 1.23400 33 1 33 1.27500 33 1.23457 33 -3.12500 33 0.0 33 1.23400 33 1 33 FAIL: test-xprintf-posix.sh This failure was due to NLS. If I run ./configure, the test fails. If I run it with --disable-nls, the test succeeds. The trouble was this definition from libintl.h: #define vprintf libintl_vprintf That ends up overriding (in xprintf.c) the one from stdio.h: #if 1 # if 1 # define vprintf rpl_vprintf And since the gettext installation there is out of date, coreutils is linked with the older, less robust, libintl_vprintf and fails the test. As for how to fix the use, in gnulib/lib/xprintf.c, ... xprintf.c uses gettext.h for definitions/decls of gettext. It gets stdio.h via xprintf.h. I could opt not to include gettext.h, then s/gettext/dcgettext/ and pull a few #ifdefs, #defines and a declaration out of gettext.h, but that sounds too ugly. Anyone see a better way?
how to use AC_LIB_LINKFLAGS with a multi-library package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How do I check for a package (ffcall) which consists of several libraries (avcall and callback)? I do not want to force the user to do pass the prefix twice: --with-avcall-prefix=/usr/local --with-callback-prefix=/usr/local I want --with-ffcall-prefix=/usr/local instead. my first attempt: AC_DEFUN([CL_FFCALL],[dnl AC_ARG_WITH([ffcall], AC_HELP_STRING([--with-ffcall],[use (default is YES, if present)]), [cl_cv_use_ffcall=$withval], [cl_cv_use_ffcall=no]) AC_CACHE_CHECK([whether to use ffcall],[cl_cv_use_ffcall],[cl_cv_use_ffcall=yes]) AC_REQUIRE([AC_LIB_PREPARE_PREFIX])dnl prerequisite of AC_LIB_LINKFLAGS_BODY AC_REQUIRE([AC_LIB_RPATH])dnl prerequisite of AC_LIB_LINKFLAGS_BODY - ---AC_LIB_LINKFLAGS_BODY([ffcall])dnl set LIBFFCALL et al if test $cl_cv_use_ffcall = yes; then AC_CACHE_CHECK([whether ffcall is present],[cl_cv_have_ffcall],[dnl cl_cv_have_ffcall=no AC_CHECK_HEADERS(avcall.h callback.h) AC_SEARCH_LIBS(__builtin_avcall,avcall) AC_SEARCH_LIBS(is_callback,callback) if test $ac_cv_header_avcall_h = yes -a $ac_cv_header_callback_h = yes \ -o $ac_cv_search___builtin_avcall = yes -o $ac_cv_search_is_callback = yes then cl_cv_have_ffcall=yes fi fi])]) is clearly wrong because there is no libffcall.so, one should be checking for libavcall.so and libcallback.so instead, so - ---AC_LIB_LINKFLAGS_BODY([ffcall]) should be replaced with - ---AC_LIB_LINKFLAGS_BODY([avcall]) - ---AC_LIB_LINKFLAGS_BODY([callback]) which will add options --with-avcall-prefix and --with-callback-prefix instead of --with-ffcall-prefix. For a moment I thought AC_LIB_LINKFLAGS_BODY([ffcall],[avcall callback]) would do the trick, but now I doubt that: there is really no libffcall library, so AC_LIB_LINKFLAGS_BODY will fail... Any suggestions? thanks. Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTJ6nPp1Qsf2qnMcRAuA8AKCDgcH9qj6Tdrt61Pf8CBhFoc22eQCeKLcC pk7k2T5dMeIqH/xuBtaRtWQ= =RX0E -END PGP SIGNATURE-
Re: copyright notice for regexprops-generic.texi
On Nov 24, 2007 11:53 AM, James Youngman [EMAIL PROTECTED] wrote:
I now notice that unfortunately the content of regexprops-generic.texi
has significantly diverged from the (one time) original source, which
is automatically generated by lib/regexprops.c in findutils.
This original contains some extra sections which are not useful in
regexprops-generic.texi, and some which are useful are in act missing.
So I've updated the findutils code (the patch is awaiting code
review) to include a makefile rule for generating
regexprops-generi.texi as well. Findutils doesn't use the file, so
it's not generated by default.
This
leaves me with a headache; which of the changes were intended to fix
defects in the documentation (and thus need feeding 'upstream' back
into findutils) and which changes are mainly editorial or intended to
adapt the file for use in other projects?
Well, this turns out not to be so bad. The changes were in fact
mostly the presence/absence of the sections I refer to above. My
confusion was caused by the fact that the automatically-generated text
is quite self-similar and so the diff was slightly confusing. So
while there are also editorial changes, they appear to be failrly
minimal and also appear to have been made by me. I attach the
relevant patch.
I find this tangle a bit frustrating since it's this kind of
difficulty that gnulib exists to prevent. Does anybody have ideas
about how we could improve the situation ? That is, how can we make
fixing this a once-only effort?
Well, once I have applied the pending patch to findutils, I will
update findutils' make check to compare the regexprops-generic.texi
it generates with the one included in gnulib. That extra automation
will take the manual work out of keeping this up to date.
2007-11-27 James Youngman [EMAIL PROTECTED]
* doc/regexprops.texi: change an close-group to a close-group
and illegal to not allowed.
--- src/gnulib-git/gnulib/doc/regexprops-generic.texi 2007-11-27 11:06:38.0 +
+++ compile/doc/regexprops-generic.texi 2007-11-27 22:42:14.0 +
@@ -192,7 +194,7 @@
@item At the end of a regular expression
[EMAIL PROTECTED] Before an close-group, signified by
[EMAIL PROTECTED] Before a close-group, signified by
@samp{\)}
@item Before the alternation operator @samp{\|}
@@ -283,7 +285,7 @@
@item At the end of a regular expression
[EMAIL PROTECTED] Before an close-group, signified by
[EMAIL PROTECTED] Before a close-group, signified by
@samp{\)}
@item Before the alternation operator @samp{\|}
@@ -441,7 +443,7 @@
@item At the end of a regular expression
[EMAIL PROTECTED] Before an close-group, signified by
[EMAIL PROTECTED] Before a close-group, signified by
@samp{\)}
@item Before a newline
@@ -499,7 +501,7 @@
The characters @samp{^} and @samp{$} always represent the beginning and end of a string respectively, except within square brackets. Within brackets, @samp{^} can be used to invert the membership of the character class being specified.
[EMAIL PROTECTED], @samp{+} and @samp{?} are special at any point in a regular expression except the following places, where they are illegal:
[EMAIL PROTECTED], @samp{+} and @samp{?} are special at any point in a regular expression except the following places, where they are not allowed:
@enumerate
@item At the beginning of a regular expression
@@ -626,7 +628,7 @@
The characters @samp{^} and @samp{$} always represent the beginning and end of a string respectively, except within square brackets. Within brackets, @samp{^} can be used to invert the membership of the character class being specified.
[EMAIL PROTECTED], @samp{+} and @samp{?} are special at any point in a regular expression except the following places, where they are illegal:
[EMAIL PROTECTED], @samp{+} and @samp{?} are special at any point in a regular expression except the following places, where they are not allowed:
@enumerate
@item At the beginning of a regular expression
@@ -696,7 +698,7 @@
@item At the end of a regular expression
[EMAIL PROTECTED] Before an close-group, signified by
[EMAIL PROTECTED] Before a close-group, signified by
@samp{\)}
@end enumerate
