Bruno Haible <[EMAIL PROTECTED]> writes:
> OK, then we have to do the review after it's already in CVS.
I hope that is not a problem. After all, the code works, and
even if it didn't work, there are currently no programs that
depend on it for them to break.
Bruno Haible <[EMAIL PROTECTED]> write
Jim Meyering <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> wrote:
>> I wanted to use verify_true instead of if...abort, but GCC -Wall
>> gave an annoying "statement with no effect" warning.
> You can use (void) verify_true (...).
Thank you. I don't know why that didn't occur to me.
On 7/23/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
'popcount' is not a particularly good name. When I first stumbled on a
function of this name in the sources of GNU gettext, it took me some time
to understand what it meant.
The ANSI Common Lisp name for this function is 'logcount', where the
p
adds a --po-base option; when specified a po/ directory for the
gnulib part is created and populated with the PO files from the
translation project.
Excuse my usual ignorance, but I'm not sure how this thread got
resolved. As maintainers, what (if anything) are we supposed to do?
In
> Similarly, if you include the LGPL in the manual (there is no
> requirement to do so, as far as I know), both gpl.texi and lgpl.texi
> should be included, in separate nodes. Yes, this is a change from the
> previous standalone lgpl.texi ...
Ok. The license was originally included in the C libr
Hi Roland,
rms and brett decided it's best for the LGPL and GPL to remain separate.
Therefore, you should include the plain text file of both -- the GPL in
COPYING, and the LGPL in COPYING.LESSER.
http://www.gnu.org/licenses/gpl-howto.html has our attempt at explaining
this.
Similarly, if you in
Hello Ben,
> I checked this in.
OK, then we have to do the review after it's already in CVS.
> 2007-07-22 Ben Pfaff <[EMAIL PROTECTED]>
>
> New module: popcount.
'popcount' is not a particularly good name. When I first stumbled on a
function of this name in the sources of GNU gettext,
Ben Pfaff wrote:
> I wanted to use verify_true instead of if...abort, but GCC -Wall
> gave an annoying "statement with no effect" warning.
verify_true() is meant to be used in an expression context. In a declaration
context (e.g. at the beginning of a function or of a compound statement)
you can u
On Mon, 2007-07-23 at 23:27 +0200, Bruno Haible wrote:
> Hello,
> mkdir confdir1
> mkdir confdir2
> echo ... > confdir1/conftest.h
> echo ... > confdir2/conftest.h
> save_CPPFLAGS="$CPPFLAGS"
> CPPFLAGS="$CPPFLAGS -Iconfdir1 -Iconfdir2"
> AC_PREPROC_IFELSE([#include ], ...)
> CPPFLA
Karl Berry wrote:
> Should there be a gnulib/uniwidth/.cvsignore file for .deps (and
> .dirstamp?), as with gnulib/lib/.cvsignore?
Indeed, this will make gnulib-tool a little bit more comfortable. I'm
applying this:
2007-07-23 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_impor
Hello,
Peter O'Gorman wrote:
> include_next.m4 incorrectly deduces that this compiler understands
> #include_next. The compiler issues a warning rather than an error when
> it sees it.
>
> This should fix:
> --- m4/include_next.m4~ 2007-07-18 03:21:47.089858027 +
> +++ m4/include_next.m4 20
On Sun, 2007-07-22 at 17:50 -0400, Gary V. Vaughan wrote:
>
> The compile completes. I suspect the problem affects all @INCLUDE_NEXT@
> using files on this host (stdio_.h is the only one that I've tripped
> over
> so far).
include_next.m4 incorrectly deduces that this compiler understands
#inc
A few weeks ago it worked, but updating my gnulib repository and
rerunning
gnulib-tool now breaks my builds on powerpc-ibm-aix4.3.3.0 as follows:
xlc -DHAVE_CONFIG_H -I. -I. -I.. -DCAIRO_NO_MUTEX -O2 -qro -
qroconst -qmaxmem=-1 -qarch=com -c printf-args.c -DPIC -o .libs/
printf-args.o
".
13 matches
Mail list logo
