Re: remove 'exit'?

k...@freefriends.org (Karl Berry) writes: > FWIW, I also agree with just removing the module instead of trying to > ever-escalate warnings. My experience is that few people are likely to > deal with it until it becomes an error regardless of warning. Alas, I don't think it becomes an error even

Re: gettext dependency?

Bruno Haible writes: > Simon Josefsson wrote: >> Gnulib's DEPENDENCIES says: >> >> * GNU gettext 0.16.1. > > Oops. that should be the newest release. Now it's 0.18.1.1. The file wasn't > updated in a long time. I'm applying this patch: Thank you! /Simon

[PATCH 1/2] conditional dependencies between modules

Paul Eggert wrote: > Thanks, I can verify that this patch worked for Emacs, in that it caused > 'configure' to not bother to test for strtoull on a host that had strtoumax. > (Emacs uses strtoumax but not strtoull directly.) Good, this means that the conditional dependencies worked also in --impor

Re: remove 'exit'?

FWIW, I also agree with just removing the module instead of trying to ever-escalate warnings. My experience is that few people are likely to deal with it until it becomes an error regardless of warning. I would agree even more with keeping the module as an "alias" for stdlib so as to avoid this s

Re: VC-tag again

On 30 April 2011 21:39, Reuben Thomas wrote: > > Great, will modify patch for that. > Attached. -- http://rrt.sc3d.org 0001-readme-release-Add-new-module-with-release-instructi.patch Description: Binary data

Re: gettext dependency?

Simon Josefsson wrote: > Gnulib's DEPENDENCIES says: > > * GNU gettext 0.16.1. Oops. that should be the newest release. Now it's 0.18.1.1. The file wasn't updated in a long time. I'm applying this patch: 2011-05-01 Bruno Haible Update DEPENDENCIES. * DEPENDENCIES (gettext):

gettext dependency?

Gnulib's DEPENDENCIES says: * GNU gettext 0.16.1. + Recommended. Needed if you use modules that use internationalization (many do). + Homepage: http://www.gnu.org/software/gettext/ + Download: http://ftp.gnu.org/gnu/gettext/ ftp://ftp.gnu.org/gnu/gettext/ Most of the other e

Re: remove 'exit'?

Simon Josefsson wrote: > How about just removing the module?  If something breaks, the maintainer > can track it down, and will notice that the module disappeared, and fix > the package. OK. I won't object any more. Feel free to remove the module. Bruno -- In memoriam Itzhak Katzenelson

Re: manywarnings.m4 indentation

Hello Pádraig, * Pádraig Brady wrote on Sat, Apr 30, 2011 at 07:02:10PM CEST: > On 30/04/11 12:13, Bruno Haible wrote: > > Pádraig Brady wrote: > >> I've amended that, and the indenting issue Bruno noticed, and pushed. > > > > That file also has other indentation issues: the basic indentation > >

Re: parse-datetime.texi contains reference to date's --iso-8601 option

Paul Eggert writes: > On 05/01/11 11:21, J.T. Conklin wrote: >> should the parse-datetime.texi documentation >> be changed to remove the "tr"; to remove the --iso-8601 example; or to >> change it from --iso-8601 to --rfc-3339 (which also does not need the >> "tr"); or would something else be more

Re: remove 'exit'?

Hello Simon, * Simon Josefsson wrote on Sun, May 01, 2011 at 09:47:06PM CEST: > Bruno Haible writes: > > 'gettextize' requires the user to press Enter to acknowledge the output. And > > it has annoyed a lot of people. Some distros patch out this part of > > gettextize. > > In summary, people don

Re: remove 'exit'?

Hello, * Bruno Haible wrote on Sun, May 01, 2011 at 09:38:43PM CEST: > > Should we just play more with boldface output? This sounds like an arms race again. Whenever that happens, it is usually most helpful in the long to consider removing output, or producing some of the other output more judi

Re: remove 'exit'?

Bruno Haible writes: > Hi Simon, > >> It is easy to miss the message -- gnulib-tool's output is quite verbose. >> Would it help if the user had to press enter to continue? That could be >> a problem for automated builds, but someone is bound to notice the >> problem eventually in that case thoug

Re: [PATCH 1/2] mark functions with const and pure attributes

Paul Eggert wrote: > The declarations should be marked. For example, the declaration of argmatch > should be marked with _GL_ATTRIBUTE_PURE (or _GL_PURE) in argmatch.h. Yes. Good point. Jim, in the current idioms with macros from c++defs.h the attribute needs to be added in the _GL_FUNCDECL_RPL

Re: remove 'exit'?

Hi Simon, > It is easy to miss the message -- gnulib-tool's output is quite verbose. > Would it help if the user had to press enter to continue? That could be > a problem for automated builds, but someone is bound to notice the > problem eventually in that case though. 'gettextize' requires the

Re: parse-datetime.texi contains reference to date's --iso-8601 option

On 05/01/11 11:21, J.T. Conklin wrote: > should the parse-datetime.texi documentation > be changed to remove the "tr"; to remove the --iso-8601 example; or to > change it from --iso-8601 to --rfc-3339 (which also does not need the > "tr"); or would something else be more appropriate I'd suggest --

Re: remove 'exit'?

Bruno Haible writes: > Simon Josefsson wrote: >> I noticed this warning in one of my projects (gsasl): >> >> Notice from module exit: >> This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. >> >> Time to remove the module? > > Well, if you were still using this module, th

parse-datetime.texi contains reference to date's --iso-8601 option

While waiting for assignment paperwork, I'm looking into what changes to the documentation and testsuite that will be needed to complete my parse-datetime.y change. In doc/parse-datetime.texi, I found a reference to the date command's --iso-8601 option in the section that explains its output may n

Re: [PATCH 1/2] mark functions with const and pure attributes

One other thing, and this is more important. The declarations should be marked. For example, the declaration of argmatch should be marked with _GL_ATTRIBUTE_PURE (or _GL_PURE) in argmatch.h. We mark functions partly so that callers can be optimized better, but typically this works for other comp

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

On 05/01/11 10:15, Gary V. Vaughan wrote: > $ cat ,t.c > #include > #include "intprops.h" > int main (int argc, char **argv) { > printf("%lu\n", (unsigned long) ULONG_MAX); > printf("%lu\n", (unsigned long) UINT_FAST8_MAX); > return 0; > } > $ cc -I. -I../lib -o ,t ,t.c && ./,t > 4294967295

Re: [bug report] sharutils-4.1.1 only builds on linux and solaris

On 05/01/11 06:46, Gary V. Vaughan wrote: Howdy Bruce! Hi Gary! I notice that the latest sharutils relies on iconv.m4 and friends from gnulib to provide --with-libiconv-prefix and --with-libintl-prefix. But, these macros are assuming that you will link using libtool,. m4/gnulib-cache.m4

Re: [PATCH 1/2] mark functions with const and pure attributes

Paul Eggert wrote: > > +# define _GL_ATTRIBUTE_PURE __attribute__ ((__pure__)) > > The names _GL_ATTRIBUTE_PURE and _GL_ATTRIBUTE_CONST seem > gratingly long to me; when reading a function signature they > get in the way of other important information. > ... > renaming them to _GL_PURE and _GL_CON

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

Hi Paul, Thanks for the pointers. On Sun, May 01, 2011 at 09:15:01AM -0700, Paul Eggert wrote: > So, the problem is that TYPE_MAXIMUM (uint_fast8_t) > expands to 2**32 - 1, whereas it should expand to > 2**64 - 1. On the contrary, it looks TYPE_MAXIMUM (uint_fast8_t) is working in both ABIs (2**

Re: remove 'exit'?

Simon Josefsson wrote: > I noticed this warning in one of my projects (gsasl): > > Notice from module exit: > This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. > > Time to remove the module? Well, if you were still using this module, that is, this notice did not catch y

fchdir dependencies

Does anyone see the reason for this dependency? Can something go wrong if I remove it? --- modules/fchdir.orig Sun May 1 18:48:07 2011 +++ modules/fchdir Sun May 1 18:47:44 2011 @@ -15,7 +15,6 @@ fcntl-h filenamecat-lgpl getcwd-lgpl -include_next malloc-posix open realloc-posix -- I

remove 'exit'?

I noticed this warning in one of my projects (gsasl): Notice from module exit: This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. Time to remove the module? /Simon

Re: [PATCH 1/2] mark functions with const and pure attributes

Paul Eggert wrote: > On 05/01/11 06:31, Jim Meyering wrote: >> +# define _GL_ATTRIBUTE_PURE __attribute__ ((__pure__)) > > The names _GL_ATTRIBUTE_PURE and _GL_ATTRIBUTE_CONST seem > gratingly long to me; when reading a function signature they > get in the way of other important information. Also,

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

So, the problem is that TYPE_MAXIMUM (uint_fast8_t) expands to 2**32 - 1, whereas it should expand to 2**64 - 1. Can you use cc -E to find what expression TYPE_MAXIMUM (uint_fast8_t) expands to, and investigate why that expansion evaluates to the wrong value? My impression is that TYPE_MAXIMUM (u

Re: [PATCH 1/2] mark functions with const and pure attributes

On 05/01/11 06:31, Jim Meyering wrote: > +# define _GL_ATTRIBUTE_PURE __attribute__ ((__pure__)) The names _GL_ATTRIBUTE_PURE and _GL_ATTRIBUTE_CONST seem gratingly long to me; when reading a function signature they get in the way of other important information. Also, these two names use a differ

Re: URL module

Hi Jose, it seems like a good idea. AFAICS, url.h has many functions, which probably are not useful to expose in a gnulib module. What functions do you exactly need? Cheers, Giuseppe jema...@gnu.org (Jose E. Marchesi) writes: > Hi Giuseppe. > > What do you think about making an 'url' gnulib

Re: RFC socketpair

>Yes, this is not very clear either. In the meantime you can play safe by > relying only on the inheritance of STDIN_FILENO and STDOUT_FILENO. > >> And unfortunatly socketpair need fd process inherance, so sad :( > > "so sad"? Just copy the 8 line of code relating to dup2() from > tests/test-nonblo

[PATCH 1/2] mark functions with const and pure attributes

Here's a better pair of patches. The first one makes gnulib-common.m4 emit definitions of these two _GL_ATTRIBUTE_... macros. The second addresses all of the warnings in gnulib code induced by building coreutils with CFLAGS='-O3 -Wsuggest-attribute=const -Wsuggest-attribute=pure -Wsuggest-attribut

Re: verify fails on ia64-hpux11.23 in libunistring-0.9.3

Hi Paul, Thanks for the response. On Sat, Apr 30, 2011 at 10:55:24PM -0700, Paul Eggert wrote: > On 04/30/11 22:10, Gary V. Vaughan wrote: > > test-stdint.o test-stdint.c > >> "test-stdint.c", line 189: error #2105: invalid size for bit field > >> verify (TYPE_MAXIMUM (uint_fast8_t) == UI

Re: [PATCH] fclose: don't fail on non-seekable input stream

Simon Josefsson wrote: > Eric Blake writes: > > > --- a/modules/fclose > > +++ b/modules/fclose > > @@ -8,6 +8,9 @@ m4/fclose.m4 > > Depends-on: > > stdio > > close > > +fflush > > +freading > > +fseeko > > I'm using the fclose module in a LGPLv2+ library and now I get: > > /home/jas/bin/gnu

Re: [PATCH] fclose: don't fail on non-seekable input stream

Eric Blake wrote: > +  /* We only need to flush the file if it is not reading or if it is > +     seekable.  */ > +  if ((!freading (fp) || fseeko (fp, 0, SEEK_CUR) == 0) && fflush (fp)) Would it be equivalent to do if ((!freading (fp) || ftello (fp) != -1) && fflush (fp)) ? Bruno -- In m

Re: git-version-gen and EXTRA_DIST

Simon Josefsson wrote: > Darn, sorry, I had a rule to remove gnulib's top-level generated lib/ > because it did not contain any source files. Instead of using the option --source-base=lib or --source-base=gl with a dummy (otherwise empty) directory, you can also use --source-base=. --makefile-n

Re: [PATCH] fclose: don't fail on non-seekable input stream

Eric Blake writes: > --- a/modules/fclose > +++ b/modules/fclose > @@ -8,6 +8,9 @@ m4/fclose.m4 > Depends-on: > stdio > close > +fflush > +freading > +fseeko I'm using the fclose module in a LGPLv2+ library and now I get: /home/jas/bin/gnulib-tool: *** incompatible license on modules:

Re: bad typo in netdb.in.h

Bruno Haible writes: > Paul Eggert wrote: >> > -# define AI_ADDRCONFIG 0 /* 0x0020: Use configuration of this >> > host to choose >> > +# define AI_ADDRCONFIG 0 /* 0x0020: Use configuration of this >> > host to choose \ >> >returned address type. */ >> >>

Re: git-version-gen and EXTRA_DIST

Jim Meyering writes: > Simon Josefsson wrote: >> Here is another approach, given that git-version-gen already includes >> some instructions for things to put in Makefile.am. >> >> But maybe there is a better approach, so let's see if we can figure out >> what makes coreutils include the script in

Re: git-version-gen and EXTRA_DIST

Simon Josefsson wrote: > Here is another approach, given that git-version-gen already includes > some instructions for things to put in Makefile.am. > > But maybe there is a better approach, so let's see if we can figure out > what makes coreutils include the script in the tarball... Hi Simon, It

Re: git-version-gen and EXTRA_DIST

Here is another approach, given that git-version-gen already includes some instructions for things to put in Makefile.am. But maybe there is a better approach, so let's see if we can figure out what makes coreutils include the script in the tarball... /Simon diff --git a/build-aux/git-version-ge

Re: git-version-gen and EXTRA_DIST

Eric Blake writes: > On 04/30/2011 09:53 AM, Simon Josefsson wrote: >> I got a report [1] that it wasn't possible to run 'autoreconf' in a >> distribution tarball because build-aux/git-version-gen was not >> distributed. Is this intended to work automatically somehow? >> Otherwise, how about thi

Re: git-version-gen and EXTRA_DIST

Bruno Haible writes: > Hi Simon, > >> I got a report [1] that it wasn't possible to run 'autoreconf' in a >> distribution tarball because build-aux/git-version-gen was not >> distributed. > > Can you show such a tarball? In coreutils-8.12.tar.gz, > build-aux/git-version-gen > is distributed. Se