Re: stat-time systemology update?
Hello again, I'm sorry that I was too quick writing my previous mail. On Wed, Oct 17, 2007 at 11:34:54AM +0200, Stepan Kasal wrote: But my GNU libc.info mentiones st_atimensec, but not st_atim. So it seems that platforms using GNU libc (GNU/Linux, Cygwin?) are converging towards POSIX. I was wrong here. st_atim seems to be the prefferred one, in current GNU libc and POSIX draft. So the only problem is that libc.info is obsolete, I'm going to report that. Sorry, Stepan
Re: check for readline
Hello, I have noticed a typo in lib/readline.c: This module is intended to be used when the application only need the readline interface. [...] the first line should end ... needs. Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Hello, On Sun, Oct 23, 2005 at 10:25:48PM -0700, Paul Eggert wrote: Simon Josefsson [EMAIL PROTECTED] writes: In file included from smbutil.c:34: lib/des.h:62: conflicting types for `des_setkey' ... If they are supposed to have the same semantics but the FreeBSD versions are buggy, you could rename the functions in unistd.h instead, by using #define before #include unistd.h. It's a bit of a hack, as it requires that client code to include your .h file before it includes unistd.h. I suppose another possibility is to use linker magic but this is a bit less portable in practice. wouldn't it be better if lib/des.h contained #include unistd.h #define des_setkey rpl_des_setkey What am I missing? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib-tool tweaks
Hi Bruno, and what about the following? Stepan 2005-10-17 Stepan Kasal [EMAIL PROTECTED] * gnulib-tool (func_create_testdir): Omit the clumsy check whether BUILT_SOURCES in nonempty. Index: gnulib-tool === RCS file: /cvsroot/gnulib/gnulib/gnulib-tool,v retrieving revision 1.86 diff -u -r1.86 gnulib-tool --- gnulib-tool 17 Oct 2005 10:27:37 - 1.86 +++ gnulib-tool 17 Oct 2005 15:26:39 - @@ -1516,11 +1516,8 @@ (cd $testdir ./configure cd lib - built_sources=`grep '^BUILT_SOURCES *=' Makefile.in | sed -e 's/^BUILT_SOURCES *=//'` - if test -n $built_sources; then - echo 'built_sources: $(BUILT_SOURCES)' Makefile - make built_sources - fi + echo 'built_sources: $(BUILT_SOURCES)' Makefile + make built_sources cd .. make distclean ) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: problems in stdbool.m4
Hello, On Fri, Oct 14, 2005 at 01:57:00PM +0200, Bruno Haible wrote: We do override include files by using our own if the system's one is defective. ... We do override an autoconf macro if it is buggy. yes, that makes sense. Thanks for explaining. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] problems in stdbool.m4
Hello, On Wed, Oct 12, 2005 at 08:23:29PM +0200, Bruno Haible wrote: Stepan Kasal wrote: I noticed two problems with stdbool.m4: Even with Autoconf-2.59, this file is included in aclocal.m4, and thus the gnulib definition overrides the Autoconf one. This is what we want. Look at the comment: -- # This macro is only needed in autoconf = 2.59. Newer versions of autoconf # have this macro built-in. AC_DEFUN([AC_HEADER_STDBOOL], but 2.59 has it's own version of AC_HEADER_STDBOOL, though slightly different from Autoconf-CVS. And the gnulib copy is different from what Autoconf-2.59 has. m4_ifndef([AC_HEADER_STDBOOL], AC_DEFUN([AC_HEADER_STDBOOL], Nope, this would be a regression. Oh, I understand now. But I don't think gnulib should redefine documented Autoconf macros. What about renaming it to gl_HEADER_STDBOOL ? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
problems in stdbool.m4
Hello, I noticed two problems with stdbool.m4: Even with Autoconf-2.59, this file is included in aclocal.m4, and thus the gnulib definition overrides the Autoconf one. Perhaps the following would fix it: m4_ifndef([AC_HEADER_STDBOOL], AC_DEFUN([AC_HEADER_STDBOOL], [... ]) ]) Second, AM_STDBOOL_H is misnamed. Wouldn't gl_STDBOOL_H be better? Wdyt? Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hello again, On Fri, Sep 23, 2005 at 10:33:21AM +0200, Stepan Kasal wrote: I'm afraid we need a design document for the solution. Simon, perhaps you could volunteer. ... or you can just wait. I think I have something in mind now, and hopefully I'll write it down sometimes next week. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Redundant AC_LIBSOURCES calls
Hello, I propose the patch attached below; an explanation follows: I think that when AC_LIBOBJ and friends was designed, the idea was to use some testing if foo_is_broken; then AC_LIBOBJ([foo]) fi The AC_LISOURCE/AC_LIBSOURCES macros were also made visible, so that the user can name additional sources, when necessary. Actually, gnulib needs foo.h in most cases, because the module fixes also a broken declaration, not only broken implementation. But in the basic case, when only the implementation is fixed and no header is needed, I see no advantage in adding a redundant call to AC_LIBSOURCES. Have a nice day, Stepan Kasal 2005-09-23 Stepan Kasal [EMAIL PROTECTED] * m4/gettime.m4, m4/getugroups.m4, m4/idcache.m4, m4/inttostr.m4, m4/nanosleep.m4, m4/settime.m4: Remove redundant AC_LIBSOURCES. Index: m4/gettime.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/gettime.m4,v retrieving revision 1.4 diff -u -r1.4 gettime.m4 --- m4/gettime.m4 26 Feb 2005 08:18:27 - 1.4 +++ m4/gettime.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_GETTIME], [ - AC_LIBSOURCES([gettime.c]) AC_LIBOBJ([gettime]) dnl Prerequisites of lib/gettime.c. Index: m4/getugroups.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/getugroups.m4,v retrieving revision 1.4 diff -u -r1.4 getugroups.m4 --- m4/getugroups.m421 Mar 2005 22:06:27 - 1.4 +++ m4/getugroups.m423 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_GETUGROUPS], [ - AC_LIBSOURCES([getugroups.c]) AC_LIBOBJ([getugroups]) dnl Prerequisites of lib/getugroups.c. Index: m4/idcache.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/idcache.m4,v retrieving revision 1.4 diff -u -r1.4 idcache.m4 --- m4/idcache.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/idcache.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_IDCACHE], [ - AC_LIBSOURCES([idcache.c]) AC_LIBOBJ([idcache]) dnl Prerequisites of lib/idcache.c. Index: m4/inttostr.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/inttostr.m4,v retrieving revision 1.4 diff -u -r1.4 inttostr.m4 --- m4/inttostr.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/inttostr.m4 23 Sep 2005 09:57:45 - @@ -8,11 +8,6 @@ [ AC_LIBSOURCES([inttostr.c, inttostr.h, intprops.h]) - dnl We don't technically need to list the following .c files, since their - dnl functions are named in the AC_LIBOBJ calls, but this is an unusual - dnl module and it seems a little clearer to do so. - AC_LIBSOURCES([imaxtostr.c, offtostr.c, umaxtostr.c]) - AC_LIBOBJ([imaxtostr]) AC_LIBOBJ([offtostr]) AC_LIBOBJ([umaxtostr]) Index: m4/nanosleep.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v retrieving revision 1.20 diff -u -r1.20 nanosleep.m4 --- m4/nanosleep.m4 2 May 2005 07:00:50 - 1.20 +++ m4/nanosleep.m4 23 Sep 2005 09:57:45 - @@ -12,8 +12,6 @@ AC_DEFUN([gl_FUNC_NANOSLEEP], [ - AC_LIBSOURCES([nanosleep.c]) - nanosleep_save_libs=$LIBS # Solaris 2.5.1 needs -lposix4 to get the nanosleep function. Index: m4/settime.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/settime.m4,v retrieving revision 1.4 diff -u -r1.4 settime.m4 --- m4/settime.m4 21 Mar 2005 22:06:27 - 1.4 +++ m4/settime.m4 23 Sep 2005 09:57:45 - @@ -6,7 +6,6 @@ AC_DEFUN([gl_SETTIME], [ - AC_LIBSOURCES([settime.c]) AC_LIBOBJ([settime]) dnl Prerequisites of lib/settime.c. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Redundant AC_LIBSOURCES calls
Hello, On Fri, Sep 23, 2005 at 02:37:06PM +0200, Bruno Haible wrote: Stepan Kasal wrote: But in the basic case, when only the implementation is fixed and no header is needed, I see no advantage in adding a redundant call to AC_LIBSOURCES. The advantage is simplicity and consistency. I thought you would object... ;-) It's only a matter of style and preferrence, no big deal. Your approach is even worse: It forces the maintainer to look or grep for AC_LIBOBJ invocations in the autoconf macros. And not only in the package's *.m4 files, but also in autoconf's and automake's own *.m4 files! It opens the door to problems that will appear with one version of autoconf and not with another... Too much magic - implies - too much complexity when debugging. The magic is already there: AC_LIBOBJ calls AC_LIBSOURCE since 2.50 when it was introduced. I don't see any chance to remove it now. This magic can complicate debugging, yes. Even though gnulib uses the redundant style, the magic is still hidden behind, ready to bite you! OK, forget about it. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex-0.12's regex.h seems to have a little bug
Hi, I don't say I'm excited about the AC_LIBSOURCE macro, ... On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote: I'm not sure what the supposed advantage with AC_LIBSOURCES was compared to the old scheme. ... but I think I do remember what was the advantage: Imagine that a new file baz.c is added to a module. Then it is possible that you upgrade the existing files, including the m4 file which checks whether baz.c is needed, but that you forget to copy the new file, or you forget to add it to the list of distributed files. With the old scheme, the bug would be detected only on platforms where baz.c is needed. Typically, the developper uses a variant of GNU system, so most of the replacements are not needed; so the bug is not detected on his platform. With the AC_LIBSOURCES, Automake uses traces to obtain the list of distributed files, so we are sure that baz.c will be distributed. (And if it wasn't copied into the project, Automake will complain on every platform, no matter whether the file would be actually built there.) Yes, you might object that the mistake described above will not happen when people use gnulib-tool. But: - with the old scheme, the module maintainer had to add the file to the module description, _twice_: to the file list and to the lib_SOURCES variable in Makefile.am section. - with the new scheme you only add something like if test $baz_works != yes; then AC_LIBOBJ([baz]) fi and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. Please note that almost always you need to add a check for the feature anyway, so the code required by the new scheme presents almost no overhead, and, more importantly, the risk that you forget to add it is minimal. So that's it. Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Preprocessor directives formatting
Hello, On Tue, Sep 13, 2005 at 10:23:32AM -0400, Derek Price wrote: [...] double-include protection should be ignored for the purposes of indenting compiler directives in headers, ... I would note that GNU indent doesn't currently support Paul's style. It supports intentation of cpp directives, but only to leave them unmodified or to indent them by a set # of spaces per nested block, without an option to make an exception for the first #if block encountered. that is a serious flaw in indent-2.2.9. A new option should be added for this: if the whole file is one big #ifndef..#endif, this outermost #ifdef would be ignored. It should be on by default. Moreover, two of the three options you mentioned are not properly documented: --preprocessor-indentationN-ppiN --remove-preprocessor-space-nlps They are missing from `Option Summary', both from the list of descriptions and from the `Cross Key' table below. I'm not sure whether indent is actively developped, but at least this bug report is filed in bug-indent archives now. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: socklen_t
Hello, On Thu, Sep 01, 2005 at 04:43:30AM -0500, Albert Chin wrote: for arg2 in struct sockaddr void; do for t in int size_t unsigned long unsigned long; do AC_TRY_COMPILE([ #include sys/types.h #include sys/socket.h int getpeername (int, $arg2 *, $t *); ],[ $t len; getpeername(0,0,len); ],[ socklen_t_equiv=$t break ]) done done I see two problems with this code: 1) Wouldn't break 2 be more appropriate? 2) The use of `break' or `continue' inside `AC_*_IFELSE' (or the obsolete AC_TRY_*) is not safe; it skips the cleanup of that macro. Something like this is better: ... ],[ socklen_t_equiv=$t ]) done test -z $socklen_t_equiv break done if -z $socklen_t_equiv; then AC_MSG_ERROR([Cannot find a type to use in place of socklen_t]) fi Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: check-module
Hello, On Mon, Jul 11, 2005 at 02:38:23PM +0200, Stepan Kasal wrote: 2005-07-11 Bruno Haible [EMAIL PROTECTED] and Stepan Kasal [EMAIL PROTECTED] * check-module: If more parameters are given, check each of them separately; add more exceptions, as noted by Jim Meyering. (check_module): New procedure. (%exempt_header): Now contains all exceptions. Jim has just committed this patch. Thanks. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Wed, Aug 24, 2005 at 10:30:44PM -0400, Sam Steingold wrote: gnulib CVS head does not contain gl_INCLUDED_REGEX. Indeed: revision 1.42 date: 2005/08/23 18:48:31; author: eggert; state: Exp; lines: +95 -109 * regex.m4 (gl_INCLUDED_REGEX): Remove; no longer used. All contents moved to gl_REGEX. (gl_REGEX): Don't bother checking whether lib/regex.c exists; assume that it does. The first change means you have to call gl_REGEX instead. The second change fixes your problem (see subj. line). the easiest way to reproduce the problem is $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/clisp login $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/clisp co -P clisp $ cd clisp $ make -f Makefile.devel check-configures Thanks for this hint. It sounds trivial for you, but it helped me a lot. Indeed, when I cp ../gnulib/m4/regex.m4 src/m4/ and apply the patch attached below, then make -f Makefile.devel check-configures There was one remaining problem: AC_GNU_SOURCE has to be called early in configure.ac. For projects which use gnulib-tool, macro gl_EARLY takes care of this; but you have to take care of it yourself. Have a nice day, Stepan Kasal ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Thu, Aug 25, 2005 at 11:06:00AM +0200, Stepan Kasal wrote: Indeed, when I cp ../gnulib/m4/regex.m4 src/m4/ and apply the patch attached below, then make -f Makefile.devel check-configures I forgot to attach the patch, sorry. Please find it attached to this mail. Stepan Kasal Index: Makefile.devel === RCS file: /cvsroot/clisp/clisp/Makefile.devel,v retrieving revision 1.136 diff -u -r1.136 Makefile.devel --- Makefile.devel 4 Aug 2005 22:21:30 - 1.136 +++ Makefile.devel 25 Aug 2005 10:12:30 - @@ -137,10 +137,13 @@ src/autoconf/aclocal.m4 : $(wildcard src/m4/*.m4) \ $(addsuffix .in,$(CLISP_CONFIGURES)) egrep '(AC_INIT|AC_PREREQ)' src/configure.in configure.ac - cat $(addsuffix .in,$(CLISP_CONFIGURES)) | egrep -v '(AC_INIT|AC_CONFIG_HEADER|AC_OUTPUT|AC_CONFIG_FILE.*(Makefile|link\.sh)|_CANONICAL_|AC_PREREQ)' configure.ac + echo AC_GNU_SOURCE configure.ac + cat $(addsuffix .in,$(CLISP_CONFIGURES)) | \ + egrep -v -e 'AC_(INIT|PREREQ|CANONICAL_|GNU_SOURCE|CONFIG_HEADER|OUTPUT)' \ + -e 'AC_CONFIG_FILE.*(Makefile|link\.sh)' configure.ac echo AC_OUTPUT configure.ac aclocal -I `pwd`/src/m4 --output=src/autoconf/aclocal.m4 - $(RM) configure.ac + #$(RM) configure.ac AUTOCONF_FILES = src/autoconf/aclocal.m4 AUTOCONF = autoconf Index: modules/regexp/configure.in === RCS file: /cvsroot/clisp/clisp/modules/regexp/configure.in,v retrieving revision 1.15 diff -u -r1.15 configure.in --- modules/regexp/configure.in 4 Aug 2005 22:10:53 - 1.15 +++ modules/regexp/configure.in 25 Aug 2005 10:12:30 - @@ -4,6 +4,7 @@ AC_PREREQ(2.57) AC_INIT(regexp, 1.0, clisp-list) +AC_GNU_SOURCE AC_CONFIG_SRCDIR(regexp.lisp) AC_CONFIG_AUX_DIR(../../src/build-aux) AC_CONFIG_HEADERS(config.h) @@ -16,7 +17,7 @@ AM_GNU_GETTEXT([external]) gl_C_RESTRICT gl_FUNC_ALLOCA -gl_INCLUDED_REGEX([regex.c]) +gl_REGEX # can we use the system-wide regex implementation? if test $ac_use_included_regex = no -a $cl_cv_regexp = yes; then ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] synced mktime.c and strtol.c from intprops.h
Hello, regarding this old patch: On Mon, Mar 14, 2005 at 04:46:10PM -0800, Paul Eggert wrote: When I updated intprops.h I forgot to make similar modifications to mktime.c and strtol.c. I installed this patch to fix that. 2005-03-14 Paul Eggert [EMAIL PROTECTED] * mktime.c (TYPE_TWOS_COMPLEMENT, TYPE_ONES_COMPLEMENT, TYPE_SIGNED_MAGNITUDE, TYPE_MINIMUM, TYPE_MAXIMUM): Sync from intprops.h. * strtol.c: Likewise. Why it is not possible to #include intprops.h? What would be wrong with the following patch? Stepan 2005-08-25 Stepan Kasal [EMAIL PROTECTED] * modules/mktime, modules/strtol: Add lib/intprops.h. * modules/xstrtol: Fix a typo in a comment. 2005-08-25 Stepan Kasal [EMAIL PROTECTED] * mktime.c, strtol.c: Include intprops.h instead of defining the same macros. Index: lib/mktime.c === RCS file: /cvsroot/gnulib/gnulib/lib/mktime.c,v retrieving revision 1.52 diff -u -r1.52 mktime.c --- lib/mktime.c23 Jun 2005 07:14:09 - 1.52 +++ lib/mktime.c25 Aug 2005 14:28:49 - @@ -62,38 +62,7 @@ ? (a) (b)\ : (a) / (1 (b)) - ((a) % (1 (b)) 0)) -/* The extra casts in the following macros work around compiler bugs, - e.g., in Cray C 5.0.3.0. */ - -/* True if the arithmetic type T is an integer type. bool counts as - an integer. */ -#define TYPE_IS_INTEGER(t) ((t) 1.5 == 1) - -/* True if negative values of the signed integer type T use two's - complement, ones' complement, or signed magnitude representation, - respectively. Much GNU code assumes two's complement, but some - people like to be portable to all possible C hosts. */ -#define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) -#define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) -#define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 (t) -1) - -/* True if the arithmetic type T is signed. */ -#define TYPE_SIGNED(t) (! ((t) 0 (t) -1)) - -/* The maximum and minimum values for the integer type T. These - macros have undefined behavior if T is signed and has padding bits. - If this is a problem for you, please let us know how to fix it for - your host. */ -#define TYPE_MINIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) 0 \ - : TYPE_SIGNED_MAGNITUDE (t) \ - ? ~ (t) 0 \ - : ~ (t) 0 (sizeof (t) * CHAR_BIT - 1))) -#define TYPE_MAXIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) -1 \ - : ~ (~ (t) 0 (sizeof (t) * CHAR_BIT - 1 +#include intprops.h #ifndef TIME_T_MIN # define TIME_T_MIN TYPE_MINIMUM (time_t) Index: lib/strtol.c === RCS file: /cvsroot/gnulib/gnulib/lib/strtol.c,v retrieving revision 1.23 diff -u -r1.23 strtol.c --- lib/strtol.c14 May 2005 06:03:58 - 1.23 +++ lib/strtol.c25 Aug 2005 14:28:49 - @@ -124,34 +124,7 @@ # define STRTOL_LONG_MAX LONG_LONG_MAX # define STRTOL_ULONG_MAX ULONG_LONG_MAX -/* The extra casts in the following macros work around compiler bugs, - e.g., in Cray C 5.0.3.0. */ - -/* True if negative values of the signed integer type T use two's - complement, ones' complement, or signed magnitude representation, - respectively. Much GNU code assumes two's complement, but some - people like to be portable to all possible C hosts. */ -# define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) -# define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) -# define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 (t) -1) - -/* True if the arithmetic type T is signed. */ -# define TYPE_SIGNED(t) (! ((t) 0 (t) -1)) - -/* The maximum and minimum values for the integer type T. These - macros have undefined behavior if T is signed and has padding bits. - If this is a problem for you, please let us know how to fix it for - your host. */ -# define TYPE_MINIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ -? (t) 0 \ -: TYPE_SIGNED_MAGNITUDE (t) \ -? ~ (t) 0 \ -: ~ (t) 0 (sizeof (t) * CHAR_BIT - 1))) -# define TYPE_MAXIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ -? (t) -1 \ -: ~ (~ (t) 0 (sizeof (t) * CHAR_BIT - 1 +# include intprops.h # ifndef ULONG_LONG_MAX # define ULONG_LONG_MAX TYPE_MAXIMUM (unsigned long long) Index: modules/mktime === RCS file: /cvsroot/gnulib/gnulib/modules/mktime,v retrieving revision 1.5 diff -u -r1.5 mktime --- modules/mktime 22 Sep 2004 15:11:04 - 1.5 +++ modules/mktime 25 Aug 2005 14:28:49 - @@ -2,6 +2,7 @@ mktime() function: convert broken-down time to linear time. Files: +lib/intprops.h lib/mktime.c m4/mktime.m4 Index: modules/strtol === RCS file: /cvsroot/gnulib/gnulib/modules/strtol,v retrieving revision 1.4 diff -u -r1.4 strtol --- modules/strtol 22 Sep 2004 15:11:04
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Thu, Aug 25, 2005 at 09:36:12AM -0400, Sam Steingold wrote: But I do not have lib/regex.c! I have regex.c in the current directory! Is it OK? yes, it is. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib textual domain?
Hello, On Sat, Aug 13, 2005 at 03:20:56PM +0200, Oskar Liljeblad wrote: For example, I was looking for translations for lib/regcomp.c in Gnulib. Is there any project that has those translations, or are they completely new? the regex module came from GNU libc, glibc. I guess that project is part of the Translation project. I believe that the Translation project contains one common translation pool, which should include messages from coreutils and from glibc. The translations from that memory should go smoothly to the translation of your project. Yes, there is some redundancy, but I believe it doesn't present any significant extra work for the translators. Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Non-standard types in public header files (was: Re: ssize_t)
Hello, this mail is a lengthy story to the most abstract solution and back to the basic one. Sorry, I couldn't have helped. The problem, of course, is that the installed header file cannot assume a config.h and the HAVE_* stuff. Indeed, this is the root of the problem. You try to find a solution which works without config.h. But this means that the installed headers contain have the required bits of information in a cryptic way. I'd pull the other end of the rope. If the information from config.h is needed, we can just install config.h along with the public headers. Of course, we have to use a different name for it, like gnutls-config.h, and we probably don't want to install the whole config.h, but just part of it. There are several ways how to get the subset of config.h: 1) create a make rule which would generate the subset from config.h 2) Both headers would be generated by configure, the template for the subset would be maintained manually. Look at http://cvs.gnome.org/viewcvs/goffice/ to see this in work. 3) Both the subset and the main config.h would be generated by autoheader. First, autoheader would have to be enhanced, according to this proposal http://lists.gnu.org/archive/html/autoconf/2005-05/msg00054.html Then, you'd give gnutls-config.h as the fourth parameter to the AC_DEFINEs which should go there. And then you'd probably need AH_BOTTOM([#include gnutls-config.h]) to include the subset into the main config.h. I'd prefer the last solution, but it requires a non-existent feature of autoconf 2.59. :-) Then we get back to gnulib: how could gnulib-tool easily hook into this? With solution 3): The gnulib m4 files would contain calls like this: AC_DEFINE([PUBLIC_SYMBOL], 1, [A description]m4_ifdef([gl_FEATURE_HEADER], [, gl_FEATURE_HEADER])) As soon as would the user define macro gl_FEATURE_HEADER, the public symbols would go to a separate file. But does this work? How can gnulib maintainers know which defines are needed by your public headers? The maintainer of the project has to define the subset for gnutls-config.h. So actually, it might be better to use the solution 2), with manually defined subset of config.h. But since the AC_DEFINE calls are not under your direct control, they are brought by some third party macros, there is a danger that some AC_DEFINE will disappear from configure and you won't notice it. So, after all, it seems that in your case the most robust solution might be 1). The script would not only select the #undef lines and accompanying comments, it would also check that all expected symbols were actually seen. So if an expected symbol disappered from config.h.in, the script would cry. End of my tale. Is it useful for you? Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE
Hello, On Sun, Aug 07, 2005 at 01:21:04PM -0400, Sam Steingold wrote: Maybe this trick is not working reliably; aclocal was not designed for this... Could you post the ad hoc created configure.in? so it seems the problem is in regex.m4, which comes from gnulib. Thus I cc this post to bug-gnulib. The macro gl_INCLUDED_REGEX contains this: m4_syscmd([test -f '$1']) ifelse(m4_sysval, 0, [ ... gl_PREREQ_REGEX ]) Macro gl_PREREQ_REGEX, which calls AC_CHECK_HEADERS_ONCE, is expanded only if the current directory contains the file regex.c (the argument to gl_INCLUDED_REGEX). For Sam: so the magic workaround should be to touch the file regex.c in the same directory where you have your artificial configure.in. For gnulib people: Why is the above trick necessary? Why should the macro expansion depend on the presence of the file? Second: just above the quoted code: test -n $1 || AC_MSG_ERROR([missing argument]) yes, the macro gl_INCLUDED_REGEX requires a parameter, but why it should be reported in runtime? (Yes, the parameter might be a shell variable, but is this done often?) Third, the name regex.m4 conflicts with a file in Automake. This can cause problems with aclocal --include. Could we perhaps rename it? Fourth, I noticed a typo; could you please apply the attached patch? Fifth: when my minmax patch is resolved (Bruno ;-), shouldn't something similar go to onceonly*.m4, too? Have a nice day, Stepan Kasal 2005-08-10 Stepan Kasal [EMAIL PROTECTED] * onceonly_2_57.m4: Really require Autoconf 2.57. Index: m4/onceonly_2_57.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/onceonly_2_57.m4,v retrieving revision 1.5 diff -u -r1.5 onceonly_2_57.m4 --- m4/onceonly_2_57.m4 18 Mar 2003 10:08:34 - 1.5 +++ m4/onceonly_2_57.m4 10 Aug 2005 09:02:40 - @@ -1,5 +1,5 @@ -# onceonly_2_57.m4 serial 3 -dnl Copyright (C) 2002-2003 Free Software Foundation, Inc. +# onceonly_2_57.m4 serial 4 +dnl Copyright (C) 2002-2003, 2005 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program @@ -27,7 +27,7 @@ dnl size reduction is ca. 9%. dnl Autoconf version 2.57 or newer is recommended. -AC_PREREQ(2.54) +AC_PREREQ(2.57) # AC_CHECK_HEADERS_ONCE(HEADER1 HEADER2 ...) is a once-only variant of # AC_CHECK_HEADERS(HEADER1 HEADER2 ...). ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: mbrtowc.m4 on mingw32
Hello Bruno, On Mon, Jul 04, 2005 at 01:18:25PM +0200, Bruno Haible wrote: On mingw32, mbrtowc.m4 detects that mbrtowc() exists, leading to link errors. Actually, mbrtowc() does not exist on this system, it's only declared in wchar.h but not actually implemented under this name. why cannot we use the Autoconf macro AC_FUNC_MBRTOWC? (I mean with current Autoconf. If there is a need to support some older versions of Autoconf, we could perhaps copy the definition of the macro to gnulib's mbrtowc.m4.) A copy of the macro is attached below; does it work for you? Have a nice day, Stepan # AC_FUNC_MBRTOWC # --- AN_FUNCTION([mbrtowc], [AC_FUNC_MBRTOWC]) AC_DEFUN([AC_FUNC_MBRTOWC], [ AC_CACHE_CHECK([whether mbrtowc and mbstate_t are properly declared], ac_cv_func_mbrtowc, [AC_LINK_IFELSE( [AC_LANG_PROGRAM( [EMAIL PROTECTED]:@include wchar.h]], [[wchar_t wc; char const s[] = ; size_t n = 1; mbstate_t state; return ! (sizeof state (mbrtowc) (wc, s, n, state));]])], ac_cv_func_mbrtowc=yes, ac_cv_func_mbrtowc=no)]) if test $ac_cv_func_mbrtowc = yes; then AC_DEFINE([HAVE_MBRTOWC], 1, [Define to 1 if mbrtowc and mbstate_t are properly declared.]) fi ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hello,
On Mon, Jun 27, 2005 at 02:08:07PM +0200, Stepan Kasal wrote:
On Thu, Jun 23, 2005 at 10:20:33PM +0200, Patrice Dumas wrote:
gnulib is an existing centralised repository, with implementations
under various licenses, but mostly they are GPL or LGPL.
Maybe there could be a note about that in the autoconf manual ?
standards.texi, which is distributed with Autoconf, mentiones it.
But perhaps there could be a direct link from Autoconf manual; could you
propose some wording?
I have received a proposal from Patrice. A slightly modified version is
attached below. Could any of the native speakers look at it?
Stepan
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.918
diff -u -r1.918 autoconf.texi
--- doc/autoconf.texi 24 Jun 2005 00:54:01 - 1.918
+++ doc/autoconf.texi 28 Jun 2005 10:17:55 -
@@ -4564,6 +4564,13 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+In case you want to use already existing files, you can have a look at
[EMAIL PROTECTED]://www.gnu.org/software/gnulib/, Gnulib}, a centralized
+repository with such portability files.
+The source files are available online
+at @uref{http://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/}
+under various licences, mostly GNU GPL or GNU LGPL.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: an archive of POSIX compat files ?
Hello,
On Tue, Jun 28, 2005 at 09:12:32AM -0400, Karl Berry wrote:
The English seems fine to me, but since Gnulib has a Texinfo manual, it
seems like it might make sense to use a multi-argument xref instead of
@uref (with rewording), as in:
@xref{Top,,,gnulib,Gnulib},
OTOH, is seems more useful to point developers to the web page than to
the info manual, which is not installed on most distributions.
Thus I think there should be both references.
What about the following variation of Keith's patch?
Stepan
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.919
diff -u -r1.919 autoconf.texi
--- doc/autoconf.texi 28 Jun 2005 13:08:29 - 1.919
+++ doc/autoconf.texi 29 Jun 2005 05:18:55 -
@@ -4564,6 +4564,14 @@
environment. Some functions may be missing or unfixable, and your
package must be ready to replace them.
+Suitable replacements for many such problem functions are available
+from @uref{http://www.gnu.org/software/gnulib/, Gnulib}, which aims
+to provide a centralized repository of such portability functions.
[EMAIL PROTECTED],,,gnulib,Gnulib}.
+The source files themselves are available online,
+under various licences, mostly GNU GPL or GNU LGPL, at
[EMAIL PROTECTED]://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/}.
+
@defmac AC_LIBOBJ (@var{function})
@acindex{LIBOBJ}
@ovindex LIBOBJS
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gcc -Wall warning for minmax.h
Hi,
On Tue, Jun 07, 2005 at 10:19:47AM -0400, Derek Price wrote:
- we have to document also the fact that AS_TR_SH AS_TR_CPP expand
to literal variable (symbol) name, if their argument is a literal
I didn't think this was important from the user's perspective.
In the patch I proposed, I used gl_CACHE_VAR as the second argument
of AC_CACHE_CHECK.
That argument cannot contain backticks, see the Appendix below.
That explains why I relied on the feature, and why I wanted to document it.
But yes, it's better to fix AC_CACHE_CHECK to remove this limitation.
After that fix, we could also remove the AS_LITERAL_IF with m4_fatal.
I'm happy that AS_LITERAL_IF will stay undocumented.
m4_fatal and m4_warning should be documented, though.
Have a nice day,
Stepan
Appendix:
If gl_CACHE_VAR expanded to
`echo xyz-xyz | sed ...`
then you get something like:
eval test \\${gl_CACHE_VAR+set}\ = set
eval test \\${`echo xyz-xyz | sed ...`+set}\ = set
And this construct is not portable, see the first paragraph of node
Shell Substitutions.
This can be fixed: AS_VAR_TEST_SET could in this case expand to
as_var=`echo xyz-xyz | sed ...`
eval test \\${$as_var+set}\ = set
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
[bug-gnulib] Re: gcc -Wall warning for minmax.h
Hello, On Fri, Jun 03, 2005 at 05:53:00PM +0200, Bruno Haible wrote: AS_TR_* are not documented in the autoconf manual You are right. I have to start by documenting AS_TR_SH, AS_TR_CPP, AS_LITERAL_IF and m4_fatal. Then I can resubmit the patch. AC_TRY_COMPILE is shorter and more mnemonic than the *_IFELSE macros. I believe there were good reasons why it was obsoleted. (Double quotes its param, and we cannot change the behaviour without renaming it.) If people continue to use it, they can experience unwanted surprises. If you use obsolete macros in your code, users will follow you. Please help spreading the message and avoid using it. - use m4_pushdef/m4_popdef instead of define/undefine This change was important. Your macro does m4_undefine([header]) and m4_undefine([HEADER]). What if these symboles were already defined? (Perhaps by another macro, written in a similar style.) An updated patch attached. Stepan 2005-06-04 Stepan Kasal [EMAIL PROTECTED] * minmax.m4 (gl_MINMAX_IN_HEADER): Don't use obsolete AC_TRY_COMPILE; use m4_pushdef/m4_popdef. Index: m4/minmax.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v retrieving revision 1.1 diff -u -r1.1 minmax.m4 --- m4/minmax.m423 May 2005 10:25:53 - 1.1 +++ m4/minmax.m44 Jun 2005 06:43:55 - @@ -19,20 +19,20 @@ dnl gl_MINMAX_IN_HEADER(HEADER) AC_DEFUN([gl_MINMAX_IN_HEADER], [ - define([header],[translit([$1],[./-], - [___])]) - define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], - [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) + AC_PREREQ(2.50) + m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]translit([$1], [./-], [___])) + m4_pushdef([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-], + [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])]) AC_CACHE_CHECK([whether $1 defines MIN and MAX], -[gl_cv_minmax_in_]header, -[AC_TRY_COMPILE([#include $1 -int x = MIN (42, 17);], [], - [gl_cv_minmax_in_]header[=yes], - [gl_cv_minmax_in_]header[=no])]) - if test $gl_cv_minmax_in_[]header = yes; then +gl_CACHE_VAR, +[AC_COMPILE_IFELSE([#include $1 + int x = MIN (42, 17);], + [gl_CACHE_VAR=yes], + [gl_CACHE_VAR=no])]) + if test $gl_CACHE_VAR = yes; then AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1, [Define to 1 if $1 defines the MIN and MAX macros.]) fi - undefine([HEADER]) - undefine([header]) + m4_popdef([HEADER]) + m4_popdef([gl_CACHE_VAR]) ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
