Eric Blake wrote:
Then you contrast it with AC_CHECK_DECL, which defines
HAVE_FUNC_DECL
to either 0 or 1, but always defines it. If you use #ifdef in those
situations, you lose (you typed 3 more bytes, and you get the wrong result).
Ok.
Just out of curiosity: is there a reason for this beh
On 03/17/2010 05:00 PM, Grégoire Sutre wrote:
> Hi Eric,
>
>> AC_CHECK_FUNCS leaves HAVE_FUNC undefined if it is missing, but defines
>> HAVE_FUNC to 1 if it is present. It is much easier to write:
>>
>> #if HAVE_FUNC
>
> In that case you only need to write:
>
> #ifdef HAVE_FUNC
>
> which is j
Hi Eric,
> AC_CHECK_FUNCS leaves HAVE_FUNC undefined if it is missing, but defines
> HAVE_FUNC to 1 if it is present. It is much easier to write:
>
> #if HAVE_FUNC
In that case you only need to write:
#ifdef HAVE_FUNC
which is just as simple, and is compliant with -Wundef.
Moreover, the docu
Hi Eric, Bruno,
On Tue, 16 Mar 2010, Eric Blake wrote:
> Indeed, bison already uses multiple submodules (gnulib and autoconf),
> and has done for more than a year. It may be worth getting Joel's
> opinions here, as the maintainer of the only GNU package that I am aware
> of that currently tracks
On 03/16/2010 05:59 PM, Grégoire Sutre wrote:
>> In fact, any package which makes good use of Autoconf cannot support
>> -Wundef.
>
> I don't see why. Could you please elaborate?
AC_CHECK_FUNCS leaves HAVE_FUNC undefined if it is missing, but defines
HAVE_FUNC to 1 if it is present. It is much
Bruno Haible wrote:
> As I understand it, 'bootstrap' currently updates all submodules when it
> wants to update only the gnulib submodule. What about packages that will have
> other submodules? Here is a proposed fix:
>
> 2010-03-14 Bruno Haible
>
> * build-aux/bootstrap: Apply "git submo
On 03/13/2010 09:33 AM, Bruno Haible wrote:
> Additionally, the user who installs a package might want to disable the C++
> part even if it is packaged as part of the tarball. I'm applying this.
>
> 2010-03-13 Bruno Haible
>
> Allow the user to disable C++ code and tests.
> * m4/an
On 03/14/2010 06:16 PM, Bruno Haible wrote:
> The reason is that unlink("..") returns 0 without having done any side effects
> on the file system. Likewise for unlink("../..").
>
> Test program:
> = foo.c
> #include
> #include
> #include
> int ma
Hi Simon,
Simon Josefsson writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Ralf,
>>
>> Ralf Wildenhues writes:
>>
>>> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET:
checking whether forkpty is declared... no
checking whether forkpty is declared... (cached) no
On 03/16/2010 01:27 AM, Bert Wesarg wrote:
> Unset GIT_DIR and GIT_WORK_TREE environment variable in test
> test-vc-list-files-git.sh.
Thanks, applied, plus a changelog entry, and this incremental change to
fix a regression from 2010-05-10:
diff --git i/tests/test-vc-list-files-git.sh
w/tests/tes
On 03/17/2010 08:24 AM, Ludovic Courtès wrote:
>> Yes, you have to unset the cache variable before the second test,
>> ac_cv_have_decl_forkpty.
>
> Then I think this patch should fix it:
>
> 2010-03-17 Ludovic Courtès (tiny change)
>
> * m4/pty.m4: Unset $ac_cv_have_decl_forkpty before
This file fails to build on darwin. Is some module dependency missing
somewhere?
depbase=`echo test-pipe-filter-gi1.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -I../gllib -I./../gllib
-I/opt/local/include -g -O2 -MT test-pipe-filter-gi1.o -MD
l...@gnu.org (Ludovic Courtès) writes:
> Hi Ralf,
>
> Ralf Wildenhues writes:
>
>> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET:
>>> checking whether forkpty is declared... no
>>> checking whether forkpty is declared... (cached) no
>>
>>> Looking at pty.m4, I’m wondering whether
Hi Ralf,
Ralf Wildenhues writes:
> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET:
>> checking whether forkpty is declared... no
>> checking whether forkpty is declared... (cached) no
>
>> Looking at pty.m4, I’m wondering whether the second
>> ‘AC_CHECK_DECL([forkpty]...])’ is ac
Bruno Haible writes:
> Actually, there are quite a number of tests that not every project may
> want to carry in its testsuite, but that should be packageable via
> --create-testdir:
> - The C++ tests of the modules 'string', 'stdlib', etc.
> - The tests that ask for the superuser password ('
15 matches
Mail list logo