Re: config.h inclusion

2005-09-14 Thread Ralf Wildenhues
Hi Paul, Simon, Bruno, * Paul Eggert wrote on Thu, Sep 15, 2005 at 01:10:53AM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > 1) Fix the files that forgot to guard inclusion by HAVE_CONFIG_H. > >This is the first patch. > > Actually, I was thinking that we should go the other way,

Re: [bug-gnulib] gnulib-tool: don't ever forget to set $dry again

2005-09-14 Thread Ralf Wildenhues
Hi Bruno, * Bruno Haible wrote on Wed, Sep 14, 2005 at 10:53:53PM CEST: > Ralf Wildenhues wrote: > > This patch makes $dry_run obsolete in favor of using $dry only. This > > way, the repeated and error-prone setting of the latter is eliminated. > > Thanks for the patch. I plan to fix this proble

Re: cygwin build problem with m4 HEAD

2005-09-14 Thread Olly Betts
On 2005-09-14, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > --- libltdl/argz.c1 Jun 2005 19:09:00 - 1.5 > +++ libltdl/argz.c14 Sep 2005 15:56:38 - > @@ -29,6 +29,7 @@ > > /* Provide our wierdo HAVE_CONFIG_H rvalue for other clients. */ > #if !defined(LTDL) && defined(HAVE

Re: config.h inclusion

2005-09-14 Thread Paul Eggert
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > 1) Fix the files that forgot to guard inclusion by HAVE_CONFIG_H. >This is the first patch. Actually, I was thinking that we should go the other way, and include config.h unconditionally (except for glibc-derived code). As far as I know, nobody o

Re: [bug-gnulib] Re: config.h inclusion

2005-09-14 Thread Bruno Haible
Ralf Wildenhues wrote: > Thinking out loud, `#if HAVE*' vs. `#ifdef HAVE*' also could be > uniformized for other values of `*' .. not sure it's worth the effort. If we were to do this, then towards #if, not towards #ifdef. $ grep '# *if HAVE_' *.h *.c | wc -l 429 $ grep '# *ifdef HAVE_' *.h *

Re: [bug-gnulib] gnulib-tool: don't ever forget to set $dry again

2005-09-14 Thread Bruno Haible
Ralf Wildenhues wrote: > This patch makes $dry_run obsolete in favor of using $dry only. This > way, the repeated and error-prone setting of the latter is eliminated. Thanks for the patch. I plan to fix this problem, alongside with the need for different echo messages in the real case vs. dry-run

Re: config.h inclusion

2005-09-14 Thread Simon Josefsson
Ralf Wildenhues <[EMAIL PROTECTED]> writes: >I have added a warning to the headers that config.h needs to be >included beforehand. Do we really need this comment? It is better to document this in doc/gnulib.texi, in my opinion. Then it will cover all files, not only the one where we rem

Re: lib-link.m4: prepend to LIBS

2005-09-14 Thread Bruno Haible
Hello Ralf, > In general, $LIBS needs to be prepended to, not appended, to allow for > static linking to succeed in the presence of deplibs already in $LIBS. Thanks for the suggestion. I don't remember having thought about this issue. But 1) This is not the expected use of AC_LIB_HAVE_LINKFLAGS.

Re: cygwin build problem with m4 HEAD

2005-09-14 Thread Ralf Wildenhues
[ replacing bug-libtool with libtool-patches ] Hi Eric, others, * Eric Blake wrote on Fri, Sep 09, 2005 at 03:36:54PM CEST: > According to Ralf Wildenhues on 9/9/2005 6:46 AM: > > > > I hate runtime checks. This one will mean hopeless complication of > > things, and worse results for any kind o

Re: config.h inclusion

2005-09-14 Thread Ralf Wildenhues
Hi Paul, * Paul Eggert wrote on Wed, Sep 14, 2005 at 01:21:18AM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > Would you accept a patch to change all of these to use > > #ifdef HAVE_CONFIG_H > > # include > > #endif > > > > uniformly? > > That makes sense to me, yes. We should be co

lib-link.m4: prepend to LIBS

2005-09-14 Thread Ralf Wildenhues
Hi Bruno, bug-gnulib readers, In general, $LIBS needs to be prepended to, not appended, to allow for static linking to succeed in the presence of deplibs already in $LIBS. With specific libraries, the issue _may_ be different, but only very rarely so[1]. This is why the patch below handles only

Re: mmapping of /dev/zero always fails on darwin

2005-09-14 Thread Bruno Haible
Derek Price wrote: > Generally, I choose to be pessimistic about test failures when > cross-compiling. Anyone have an opinion about whether I should be > pessimistic always or just when the target system name matches gcc's > list of systems which fail this test? Generally, I try to use this appro