Eric Blake wrote:
> * top/maint.mk (sc_makefile_at_at_check): Enhance check to cover
> lower case, like @top_srcdir@.
>
> Signed-off-by: Eric Blake
> ---
>
> Any objections to this? I noticed that libvirt had a mix
> of $(top_srcdir) and @top_srcdir@ in the same variable, and
> traced it to a wea
On 02/02/2012 08:14 PM, Jens Staal wrote:
> So I should use *rp and *wp
> - but how?
I suggest getting a copy of the Plan 9 source code,
and looking at how getchar and putchar work.
2012/2/2 Paul Eggert :
> On 02/02/2012 03:04 AM, Jens Staal wrote:
>> do I need a custom made one
>> and how should that one look?
>
> That's what it looks like. You can start by inspecting
> and look for fields in its FILE * structure.
The Plan9 APE stdio can be seen here:
http://plan9.bell-la
Eric Blake wrote:
> But which order is preferred?
>
> The gnulib manual recommends:
> AM_CPPFLAGS = -I$(top_builddir)/lib -I$(top_srcdir)/lib
It is like this on purpose. As Mike has explained, there are situations
(which shouldn't occur but somehow do occur in rare cases) where the
.h file is lef
On Tue, Jan 17, 2012 at 07:16:34PM +0100, Bruno Haible wrote:
> Hi Jiri,
>
> > Log and tarball of requested files in attachment.
>
> Thanks, but the allocator.i file is unusable. It contains two commands
> instead of a preprocessed output. I need the result of the command
>
> gcc -std=gnu99 -DHA
* top/maint.mk (sc_makefile_at_at_check): Enhance check to cover
lower case, like @top_srcdir@.
Signed-off-by: Eric Blake
---
Any objections to this? I noticed that libvirt had a mix
of $(top_srcdir) and @top_srcdir@ in the same variable, and
traced it to a weak syntax check not catching the di
On Thursday 02 February 2012 15:40:59 Eric Blake wrote:
> Yes, hacks like that render the question of stale files moot. But
> without resorting to sledge-hammers, can we come to a consensus on which
> way things should listed be in a best-practices project?
i have my personal opinion, but i'm amb
On 02/02/2012 01:43 PM, Jim Meyering wrote:
>> And coreutils has a bug, for forgetting the builddir version (which
>> means it will build in an in-tree build, but probably fail in a VPATH
>> build):
>> AM_CPPFLAGS = -I$(top_srcdir)/lib
>
> "forgetting"? ;-) Nah.
> On the contrary, I vaguely recal
Eric Blake wrote:
> The manual (gnulib-tool.texi) recommends including both builddir and
> srcdir into AM_CPPFLAGS (aka INCLUDES if you are using automake 1.9),
> which makes sense, since some headers come straight from gnulib and live
> in srcdir, while other headers are generated based on config
On 02/02/2012 01:28 PM, Mike Frysinger wrote:
> On Thursday 02 February 2012 15:10:11 Eric Blake wrote:
>> Is there any specific reason that gnulib recommends builddir (generated
>> files) before srcdir?
>
> my gut tends to prefer builddir over srcdir. but that could be due more to
> poorly mana
On Thursday 02 February 2012 15:10:11 Eric Blake wrote:
> Is there any specific reason that gnulib recommends builddir (generated
> files) before srcdir?
my gut tends to prefer builddir over srcdir. but that could be due more to
poorly managed packages than a "best practices" setup. in cases wh
The manual (gnulib-tool.texi) recommends including both builddir and
srcdir into AM_CPPFLAGS (aka INCLUDES if you are using automake 1.9),
which makes sense, since some headers come straight from gnulib and live
in srcdir, while other headers are generated based on configure results
and thus live i
On 02/02/2012 03:04 AM, Jens Staal wrote:
> do I need a custom made one
> and how should that one look?
That's what it looks like. You can start by inspecting
and look for fields in its FILE * structure.
FYI,
>From 93f8bee70d1bc611bead8a826edf0a932c2b8999 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 2 Feb 2012 09:12:13 +0100
Subject: [PATCH] file-has-acl: suppress a warning from gcc
-Wsuggest-attribute=const
* lib/file-has-acl.c (file_has_acl): This function (for some #ifdefs)
would e
14 matches
Mail list logo
