Bruno Haible wrote:
>> Here's a proposed patch that uses the idiom presented in [1].
>
> Applied as well, due to absence of objections.
>
> 2011-04-05 Bruno Haible
>
> Remove leftover generated .h files after config.status changed.
>
> * m4/alloca.m4 (gl_FUNC_ALLOCA): New automake co
On 04/05/2011 03:21 PM, Bruno Haible wrote:
> Isn't the first part of this condition a bit optimistic?
I suppose it is. Chalk me down as Candide.
I installed the patch without the __STDC_VERSION__ business,
and thanks to Eric and you for the reviews.
On 04/05/2011 04:50 PM, Bruno Haible wrote:
> I've made the change, assuming that Paul's commit to lib/pipe.c, which only
> removed some lines of code, is not relevant for copyright purposes
I expect you're right about copyright, but just in case: the change
is fine with me too. And thanks.
> Here's a proposed patch that uses the idiom presented in [1].
Applied as well, due to absence of objections.
2011-04-05 Bruno Haible
Remove leftover generated .h files after config.status changed.
* m4/alloca.m4 (gl_FUNC_ALLOCA): New automake conditional
GL_GENERAT
> > 2011-04-02 Bruno Haible
> >
> > Ensure to rebuild generated .h files when config.status has changed.
> > * modules/arpa_inet (Makefile.am): Add dependency from .h file to
> > config.status.
> > * modules/ctype (Makefile.am): Likewise.
> > ...
I've applied this now.
Bru
Eric Blake wrote:
> I don't see pipe2 as adding much beyond pipe-posix, cloexec, or
> nonblocking, all of which are LGPLv2+, and libvirt would really like to
> start using atomic fd flag creation routines like pipe2() to avoid data
> races on new enough Linux (the race is still present on other OSs
I don't see pipe2 as adding much beyond pipe-posix, cloexec, or
nonblocking, all of which are LGPLv2+, and libvirt would really like to
start using atomic fd flag creation routines like pipe2() to avoid data
races on new enough Linux (the race is still present on other OSs, but
the code is simpler
Hi Paul,
> +# if (201104 <= __STDC_VERSION__ \
> + || 4 < __GNUC__ || (__GNUC__ == 4 && 6 <= __GNUC_MINOR__))
> +# define HAVE__STATIC_ASSERT 1
Isn't the first part of this condition a bit optimistic? I think that
experience in the past has shown that compiler vendors tend to bump the
__STD
On 04/05/11 13:40, Eric Blake wrote:
The order-that-I-put-them-in rule. In general, I think I understand
stuff better than a computer, so why am I being over-ruled?
I tend to like sorted files (if nothing else, the human brain is much
better at finding lines in a sorted file than a random one,
On 04/05/2011 02:43 PM, Bruce Korb wrote:
> * build-aux/bootstrap (gnulib_extra_files): bootstrap.conf may
> change build_aux or also supply gnulib_extra_files. Handle correctly.
> +# Extra files from gnulib, which override files from other sources.
> +test -z "${gnulib_extra_files}" && \
I'm no
On 04/04/2011 08:26 PM, Paul Eggert wrote:
> This gnulib patch modifies "verify" to use C1X's _Static_assert if
> running GCC 4.6.0 or later, which generates easier-to-read
> diagnostics. I haven't pushed this yet because I thought it wouldn't
> hurt to get more pairs of eyes to look at it.
Cool
* build-aux/bootstrap (gnulib_extra_files): bootstrap.conf may
change build_aux or also supply gnulib_extra_files. Handle correctly.
---
ChangeLog |6 ++
build-aux/bootstrap | 27 ++-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/Cha
On 04/05/2011 02:19 PM, Bruce Korb wrote:
>> What order-dependent sorting rules do you have, that would not already
>> be covered by sinking ! lines to the bottom of the .gitignore file per
>> the patch I just posted there?
>
> The order-that-I-put-them-in rule. In general, I think I understand
>
This has bugged me for a while...
/Simon
* top/maint.mk (sc_prohibit_empty_lines_at_EOF): Don't trigger
sc_space_tab check.
---
ChangeLog|5 +
top/maint.mk |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 96804fa..6fc0ef3 100644
--
On 04/05/11 12:58, Eric Blake wrote:
On 04/05/2011 01:19 PM, Bruce Korb wrote:
This fixes two things:
1. "gnulib_extra_files" should not be computed before sourcing the
bootstrap.conf file, unless you intend that overriding build_aux
forces overriding gnulib_extra_files, too. I don't t
On 04/05/2011 01:19 PM, Bruce Korb wrote:
> This fixes two things:
>
> 1. "gnulib_extra_files" should not be computed before sourcing the
>bootstrap.conf file, unless you intend that overriding build_aux
>forces overriding gnulib_extra_files, too. I don't think so, so
>I deferred its
In .gitignore, it is handy to do:
/m4/*
!/m4/file.m4
to whitelist just file.m4 while ignoring all other files. But
! sorts too early.
* build-aux/bootstrap (sort_patterns): New function.
(insert_sorted_if_absent): Use it to float ! lines to the bottom.
---
build-aux/bootstrap | 21 ++
This fixes two things:
1. "gnulib_extra_files" should not be computed before sourcing the
bootstrap.conf file, unless you intend that overriding build_aux
forces overriding gnulib_extra_files, too. I don't think so, so
I deferred its computation until afterward.
2. I also ran into a pr
Following up on Ben Pfaff's comments, I installed
the patch into gnulib, with the following further changes:
diff --git a/lib/allocator.h b/lib/allocator.h
index 54cc5ff..4ac863b 100644
--- a/lib/allocator.h
+++ b/lib/allocator.h
@@ -21,8 +21,15 @@
#include
+/* An object describing a memory
On 05/04/11 13:36, Philipp Thomas wrote:
> GNU find will not recognize file systems of type autofs on newer Linux
> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> is /etc/mtab.
>
> After a lo
GNU find will not recognize file systems of type autofs on newer Linux
kernels as autofs entries are only listed in /proc/mounts and mountlist.c
includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
is /etc/mtab.
After a longer discussion, we (SUSE) chose to patch mountlist.c
21 matches
Mail list logo
