> Here's what I'm committing, based on your original patches. This shows only
> the non-repetitive part of the commit. For the entire commit, please look
> in git.
Nice. Thanks for following up.
Two comments:
1) Is it so bad to drop the complicated code for 0.9-0.9.3 version
detection, and just
Ralf Wildenhues writes:
> * Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST:
>> Ralf Wildenhues writes:
>> > Well, one could prepend LOG_COMPILER (the default variable that doesn't
>> > go with any specified extension) or have the developer specify some
>> > other extension. Your m
* Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST:
> Ralf Wildenhues writes:
> > Well, one could prepend LOG_COMPILER (the default variable that doesn't
> > go with any specified extension) or have the developer specify some
> > other extension. Your macro could just set some variabl
Hello Ian,
* Ian Beckwith wrote on Wed, May 19, 2010 at 03:54:52AM CEST:
> * trap with signal numbers
>
> According to http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html
> (btw, am I right in saying "The Open Group Base Specifications Issue 6
> IEEE Std 1003.1, 2004 Edition" is POS
On Tue, May 18, 2010 at 08:36:28PM +0200, Simon Josefsson wrote:
> The pwrite self-test fails under Cygwin, is this a known issue?
No :)
>
> http://autobuild.josefsson.org/gnulib/log-201005172227940062000.txt
Hmm, it succeeds writing a byte at (off_t)-1? I guess you end up with a
very large spa
Hi,
I got a bug report in debian about bashisms in gnulib
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581105).
Working with a POSIX shell is a release goal for debian squeeze,
along with a switch to dash as /bin/sh.
I had a look with checkbashisms (from the devscripts package in debian
and
The pwrite self-test fails under Cygwin, is this a known issue?
http://autobuild.josefsson.org/gnulib/log-201005172227940062000.txt
/Simon
Hi Paolo,
Adding to the discussion from 2010-04-11: One point we did not think about
is versioning. New versions of libunistring are released with enhanced
functionality (more functions, or bug fixes). If the using package requires
that functionality, it imposes a constraint on the libunistring ve
One more:
>From 68e3d00f99416b0d007e9ef9c7841488ea696e3d Mon Sep 17 00:00:00 2001
From: Richard Jones
Date: Tue, 18 May 2010 17:52:12 +0200
Subject: [PATCH] doc: users.txt: list hivex
* users.txt: Add hivex.
2010-05-18 Richard Jones
---
ChangeLog |5 +
users.txt |1 +
2 files ch
FYI, Rich just noticed that febootstrap was not listed:
>From 0f178efdf4e5bb64e6223396375a2f16e6ac8d93 Mon Sep 17 00:00:00 2001
From: Richard Jones
Date: Tue, 18 May 2010 16:52:35 +0200
Subject: [PATCH] doc: users.txt: list febootstrap
* users.txt: Add febootstrap.
---
ChangeLog |5 +
On 05/18/2010 03:06 AM, Bruno Haible wrote:
> Hi Eric,
>
>> Typo in the ChangeLog; s/AM_DEFUN_ONCE/AC_DEFUN_ONCE/
>
> Oops. Fixed now. Thanks.
>
>>> +m4_version_prereq([2.64],[AC_DEFUN_ONCE],[AC_DEFUN])([AM_ICONV],
>>
>> ... rather than have a version check, I'd rather see:
>>
>> m4_ifdef([AC_D
Bruno Haible writes:
> The approach I use in GNU gettext is similar: Makefile.am has this:
>
> # For debugging memory leaks and memory allocation bugs.
> # You should build with --disable-shared when using valgrind.
> CHECKER =
> #CHECKER = valgrind --tool=memcheck
> --suppressions=$(srcdir)/../
Hi Eric,
> Typo in the ChangeLog; s/AM_DEFUN_ONCE/AC_DEFUN_ONCE/
Oops. Fixed now. Thanks.
> > +m4_version_prereq([2.64],[AC_DEFUN_ONCE],[AC_DEFUN])([AM_ICONV],
>
> ... rather than have a version check, I'd rather see:
>
> m4_ifdef([AC_DEFUN_ONCE],[AC_DEFUN_ONCE],[AC_DEFUN])([AM_ICONV],
Remem
Bruno Haible writes:
> Ralf Wildenhues wrote:
>> > However, in general, tests might be executable programs, or
>> > they might be shell or other scripts. In the latter cases, putting
>> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
>> > to check bash or perl).
>
> Not
Ralf Wildenhues wrote:
> > However, in general, tests might be executable programs, or
> > they might be shell or other scripts. In the latter cases, putting
> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
> > to check bash or perl).
Not only it's a waste. It also prod
Ben Pfaff wrote:
> * In GNU PSPP, which mostly uses the built-in Automake
> test framework, the invocations of the test programs
> are all through shell scripts. Each invocation of a
> test program is preceded by $SUPERVISOR,
> e.g. "$SUPERVISOR pspp
Ralf Wildenhues writes:
>> > With Automake 1.11's parallel-tests option, you have the possibility
>> > to specify per-extension "compilers" for tests.
>> >
>> > Example:
>> > # .sh and .pl files are processed to .log files.
>> > TEST_EXTENSIONS = .sh .pl
>> > SH_LOG_COMPILER = bash -vx
>> >
17 matches
Mail list logo
