scripts!!
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
$po_download_command_format |sed 's,[^%]*\(%[^%]\),\1,g'` in
%s%s) ;;
*) fatal 'invalid format in $po_download_command_format' ;;
esac
??
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
From a private discussion about preventing CFLAGS getting -std=gnu99 twice,
that leads to a bug report for gnulib and maybe autoconf too...
Begin forwarded message:
From: Gary V. Vaughan g...@gnu.org
Subject: Re: Getting AC_PROG_CC_C99
Date: 28 September 2011 12:38:33 GMT+07:00
To: Reuben
,
--
Gary V. Vaughan (gary AT gnu DOT org)
On 29 Sep 2011, at 16:14, Bruno Haible wrote:
Gary V. Vaughan wrote:
Autoconf makes it easy to enforce and document these kinds of order
dependencies though:
AC_DEFUN([gl_EARLY], [
...
AC_BEFORE([$0], [AC_PROG_CC_C99])
...
])
Rather, the order should be that AC_PROG_CC_STDC
Hi Bruno,
On 29 Sep 2011, at 16:14, Bruno Haible wrote:
Gary V. Vaughan wrote:
we're fine as-is, since it's normal practice
to put the AC_PROG_CC_STDC before gl_EARLY.
I discovered the multiple --std=gnu99 option problem because no
one told me that it's normal to to put AC_PROG_CC_STDC
.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Hi Jim,
Sorry I didn't notice your reply sooner.
On 22 Sep 2011, at 23:38, Jim Meyering wrote:
Gary V. Vaughan wrote:
* g...@github.com:gvvaughan/GNU-coreutils.git in gary/bootstrap
https://github.com/gvvaughan/GNU-coreutils/commits/gary/bootstrap
I'll try to find time for this next week
and
how to fix it, please ask!
(Bear in mind that the goal posts could be moving next week if Apple
releases a new XCode with a new gcc build for the impending iOS 5 release).
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
On 2 Oct 2011, at 19:23, Gary V. Vaughan wrote:
$ grep stpncpy /usr/include/*
/usr/include/string.h:char*stpncpy(char *, const char *, size_t)
__OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3;
Cut-n-paste error, sorry. The trailing ')' is not missing in the real string.h
header
On 2 Oct 2011, at 21:31, Gary V. Vaughan wrote:
On 2 Oct 2011, at 19:23, Gary V. Vaughan wrote:
$ grep stpncpy /usr/include/*
/usr/include/string.h:char*stpncpy(char *, const char *, size_t)
__OSX_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_3;
Cut-n-paste error, sorry. The trailing
Hi Jim,
On 4 Oct 2011, at 17:09, Jim Meyering wrote:
Gary V. Vaughan wrote:
Sorry I didn't notice your reply sooner.
On 22 Sep 2011, at 23:38, Jim Meyering wrote:
Gary V. Vaughan wrote:
* g...@github.com:gvvaughan/GNU-coreutils.git in gary/bootstrap
https://github.com/gvvaughan/GNU
to Lion.
If it's easy for you, I would love to see a new gettext release... and if
not, I think a large font warning that the latest released version needs a
patch from MacPorts to compile on Mac OS would save plenty of Homebrew
users from scratching their heads :)
Cheers,
--
Gary V. Vaughan (gary
Hi Jim,
On 5 Oct 2011, at 00:16, Jim Meyering wrote:
Gary V. Vaughan wrote:
On 4 Oct 2011, at 17:09, Jim Meyering wrote:
Do you feel like rebasing it?
Sure, although it will take me a few days to find the time - is that because
you're planning to adopt my bootstrap script into coreutils
Hi Bruno,
On 5 Oct 2011, at 18:54, Bruno Haible wrote:
Gary V. Vaughan wrote:
the normal way to install packages, for people who
are not used to fiddling with source code, is through MacPorts,
and MacPorts carries gettext 0.18.1.1 with the fix.
Actually MacPorts is not that widely used
Hi Jim,
On 5 Oct 2011, at 14:08, Gary V. Vaughan wrote:
On 5 Oct 2011, at 00:16, Jim Meyering wrote:
Gary V. Vaughan wrote:
I haven't had time yet to pick up the coreutils bootstrap.conf update, but
I'll probably be able to get to it by the end of the week. If you're in a
hurry, then I
2011, at 07:18, Gary V. Vaughan wrote:
The buildreq variable is a table that now also includes a column for the
homepage of
any requirements so that the error message can inform the user where to fetch
any
missing prerequisites.
Note also that autoconf, automake, libtool and gettext
Hi Jim,
On 6 Oct 2011, at 07:18, Gary V. Vaughan wrote:
Please find attached my updated bootstrap.conf to work with the coreutils
master.
I tested it alongside an upgraded bootstrap script from zile master:
http://git.savannah.gnu.org/cgit/zile.git/plain/bootstrap
Note that I've fixed
[[Cc: Bruno in the hope of advice on the right approach]]
Hi Pádraig,
On 6 Oct 2011, at 16:13, Pádraig Brady wrote:
On 10/06/2011 09:28 AM, Gary V. Vaughan wrote:
autopoint and gettext are synonymous, right? If not, only the gettext-0.18.1
check is made automatically, and I need to figure
Hi Paul,
2 month thread anniversary bump. Have you had the time to make a start on
anything yet? Is there anything I can do to help keep things moving?
On 8 Sep 2011, at 01:56, Gary V. Vaughan wrote:
Bumping this thread back to the top of the pile for it's 1 month
anniversary...
On 24
dev version of my clcommit script, but thanks to Libtool
needing to work with 'Gary V. Vaughan' and Peter O'Gorman, I had to be sure
it worked all along :) Despite not having the script to check, I'm pretty
sure it was just a matter of quoting carefully:
--author='Daniel Richard G. sk
raining season storms; my
electricity and Internet have been off and on a lot recently.
On 7 Oct 2011, at 02:54, Bruno Haible wrote:
Gary V. Vaughan wrote:
There is
an underlying assumption here that if AM_GNU_GETTEXT was seen in
configure.ac,
then
gettext was checked for already, and so
[[Bruno, I've kept you in for the gnulib-tool or autopoint bug I'm
intimating near the bottom of this message.]]
Hi Jim,
On 16 Oct 2011, at 04:15, Jim Meyering wrote:
Gary V. Vaughan wrote:
Is there anything else I can do to help you incorporate this, and the
matching bootstrap.conf I wrote
Hi Bruno,
On 16 Oct 2011, at 15:58, Bruno Haible wrote:
Gary V. Vaughan wrote:
If there is a bug in gnulib-tool, or autopoint that puts unnecessary
'intl/' references into Makefiles when the presence of
AM_GNU_GETTEXT_VERSION in configure.ac is a declaration that says there
is no need
100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-10-19 Gary V. Vaughan g
Ping?
On 16 Oct 2011, at 18:28, Gary V. Vaughan wrote:
On 16 Oct 2011, at 15:58, Bruno Haible wrote:
Gary V. Vaughan wrote:
If there is a bug in gnulib-tool, or autopoint that puts unnecessary
'intl/' references into Makefiles when the presence of
AM_GNU_GETTEXT_VERSION in configure.ac
Ping?
On 16 Oct 2011, at 12:50, Gary V. Vaughan wrote:
Hi Jim,
On 16 Oct 2011, at 04:15, Jim Meyering wrote:
Gary V. Vaughan wrote:
Is there anything else I can do to help you incorporate this, and the
matching bootstrap.conf I wrote for you into coreutils now that the
release is out
Ping?
On 8 Oct 2011, at 12:54, Gary V. Vaughan wrote:
Hi Paul,
2 month thread anniversary bump. Have you had the time to make a start on
anything yet? Is there anything I can do to help keep things moving?
On 8 Sep 2011, at 01:56, Gary V. Vaughan wrote:
Bumping this thread back
Hi Jim,
On 19 Oct 2011, at 20:13, Jim Meyering wrote:
Gary V. Vaughan wrote:
Jim, please consider pulling it into coreutils master as a better fix than
twidding Makefiles after the fact in bootstrap.conf.
This -Iintl option will disappear with gettext version 0.19 - because
then gettextize
Ping?
On 16 Oct 2011, at 18:28, Gary V. Vaughan wrote:
On 16 Oct 2011, at 15:58, Bruno Haible wrote:
Gary V. Vaughan wrote:
If there is a bug in gnulib-tool, or autopoint that puts unnecessary
'intl/' references into Makefiles when the presence of
AM_GNU_GETTEXT_VERSION in configure.ac
Ping?
On 16 Oct 2011, at 12:50, Gary V. Vaughan wrote:
Hi Jim,
On 16 Oct 2011, at 04:15, Jim Meyering wrote:
Gary V. Vaughan wrote:
Is there anything else I can do to help you incorporate this, and the
matching bootstrap.conf I wrote for you into coreutils now that the
release is out
Hi Jim,
On 20 Oct 2011, at 23:44, Jim Meyering wrote:
Gary V. Vaughan wrote:
On 19 Oct 2011, at 20:13, Jim Meyering wrote:
Gary V. Vaughan wrote:
Jim, please consider pulling it into coreutils master as a better fix than
twidding Makefiles after the fact in bootstrap.conf.
This -Iintl
a script relative to the current directory unless . is in
the command search PATH.
List the standard GNU email addresses to announce a release.
---
diff --git a/ChangeLog b/ChangeLog
index 25790a6..8b0f6a5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2011-10-21 Gary V. Vaughan g
Hi Bruno,
On 21 Oct 2011, at 06:58, Bruno Haible wrote:
Gary V. Vaughan wrote:
On the other hand, if by incremental you really mean chunking my rewrite
into
patches that add a function here and there, and disable bits of the old
script
when they are no longer called, then I could
the
Autoconf manual, chapter Portable Shell Programming, updated.
I had misremembered my old bash-2.05 doing it that way, but I've long since
moved to a zsh login shell which doesn't have that problem. I'll remove
that and repost after addressing Jim's review too.
Cheers,
--
Gary V. Vaughan (gary
Hi Jim,
On 21 Oct 2011, at 15:17, Jim Meyering wrote:
Gary V. Vaughan wrote:
I made these changes in gnulib-local/top/README-release while making
a start at leveraging the gnulib release machinery into GNU Libtool,
but they seem generally applicable too.
Thanks for the suggestions
Hi Jim,
On 22 Oct 2011, at 03:06, Jim Meyering wrote:
Gary V. Vaughan wrote:
As it stands (without this patch), README-release recommends:
git checkout master
git pull
./configure
make maintainer-clean
./bootstrap
Running the (potentially) outdated configure, to build
Hi Jim,
On 22 Oct 2011, at 17:15, Jim Meyering wrote:
Gary V. Vaughan wrote:
If you want to clean the cruft out of your working directories before
starting the release process, you should do it before you change branches
and merge changes from upstream, using the Makefile that you already
Hi Stefano,
On 23 Oct 2011, at 00:20, Stefano Lattarini wrote:
Hi everybody. Just my two cents about this matter ...
On Saturday 22 October 2011, Bruno Haible wrote:
Gary V. Vaughan wrote:
Running the (potentially) outdated configure, to build a (potentially)
outdated Makefile, which may
-23 Gary V. Vaughan g...@gnu.org
+
+ maint.mk: don't maintain a second build-aux variable.
+ * maint.mk (build_aux): Removed. The maintainer-makefile module
+ depends on GNUmakefile, which already maintains a cfg.mk
+ overridable $(_build-aux) for projects with a non
Hi Jim,
On 25 Oct 2011, at 00:37, Jim Meyering j...@meyering.net wrote:
Gary V. Vaughan wrote:
I was wondering why 'make stable' would always use a stale version unless
I manually updated my .version file first. It turns out that if you use
a non-standard build-aux location, you have to tell
Hi Jim,
On 25 Oct 2011, at 00:37, Jim Meyering wrote:
Gary V. Vaughan wrote:
_build-aux = libltdl/build-aux
Wouldn't that break things for those who customize build_aux?
Ah, I see what you mean now (will it break for clients who are
customizing with build_aux already).
No, I don't think
be very happy to hear about it... in the mean time, I'll try to
remember not to reply to bug-gnulib on my iPad over morning coffee.
Gary V. Vaughan wrote:
To what advantage over factoring out the duplication entirely at the
source of the problem with the patch I submitted?
Not breaking some
Hi Jim,
On 25 Oct 2011, at 15:18, Gary V. Vaughan wrote:
On 25 Oct 2011, at 15:05, Jim Meyering wrote:
Actually, I think we can both get what we want.
I suggest to adjust your patch so that make is guaranteed to fail
with a nice diagnostic for anyone who defines build_aux in cfg.mk.
It's
Hi Jim,
On 27 Oct 2011, at 22:02, Jim Meyering wrote:
Gary V. Vaughan wrote:
On 25 Oct 2011, at 15:18, Gary V. Vaughan wrote:
On 25 Oct 2011, at 15:05, Jim Meyering wrote:
Actually, I think we can both get what we want.
I suggest to adjust your patch so that make is guaranteed to fail
that does not override the default.
Oh, ouch. Sorry about that. I should have tested without a cfg.mk
override before submitting, but didn't think to look because it was
working fine in my tree without the patch. My bad.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Hi Peter,
On 31 Oct 2011, at 22:24, Peter Rosin wrote:
Gary V. Vaughan skrev 2011-10-23 18:17:
We already have to enter all the ChangeLog relevant information into the git
commit log. Instead of worrying about keeping them all in sync, this patch
generates the current year ChangeLog from
@@ -1,3 +1,16 @@
+2011-11-01 Gary V. Vaughan g...@gnu.org
+
+ gitlog-to-changelog: support multi-author commits.
+ The FSF cares about keeping track of all authors of patches to its
+ projects, but Git doesn't provide obvious support for multi-author
+ changesets. Consensus
insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f370be6..d59d9f9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2011-11-01 Gary V. Vaughan g...@gnu.org
+ gitlog-to-changelog: support `tiny change' commits.
+ The FSF insist that all non-trivial patches
Hi Jim, Karl,
On 1 Nov 2011, at 20:13, Jim Meyering wrote:
Gary V. Vaughan wrote:
diff --git a/ChangeLog b/ChangeLog
index f370be6..d59d9f9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2011-11-01 Gary V. Vaughan g...@gnu.org
+gitlog-to-changelog: support `tiny change
and
doubling
of `ten' frequently, so no one will misunderstand those mis-spellings :)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Ping Karl...
Depending on your thoughts, I will resubmit this patch series for gnulib
rather than keeping the patches solely in Libtool's tree.
On 1 Nov 2011, at 20:56, Gary V. Vaughan wrote:
On 1 Nov 2011, at 20:13, Jim Meyering wrote:
Gary V. Vaughan wrote:
diff --git a/ChangeLog b
their patch generates, or by running git diff).
Even if somewhere you've felt insistence on this issue,
let's just write request:
(tiny change) is more than a request.
That is my impression too.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Hi Jim,
Sorry for the long wait. With the flooding in Bangkok affecting everything,
I've had very spotted access to the Internet, otherwise I would have responded
sooner.
On 1 Nov 2011, at 20:09, Jim Meyering wrote:
Gary V. Vaughan wrote:
More generally useful gnulib-local goodness from my
is already known, via the associated patch.
Gary V. Vaughan wrote:
This is a confusion brought about by the 'Tiny change' misnomer I think. If
it were a simple matter of counting lines, then you would be entirely correct
of course, but what about a refactoring that moves code around
I omitted the ChangeLog and git log entry for the commit-msg script,
now fixed in my private branch as follows:
On 15 Nov 2011, at 12:04, Gary V. Vaughan wrote:
The FSF cares about keeping track of all authors of patches to its
projects, but Git doesn't provide obvious support for multi
Okay to push?
* top/maint.mk (tight-scope.mk): Make sure to prefix file
reference with $(srcdir) so that the file is found correctly even
when running `make syntax-check' in a VPATH build.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
ChangeLog|7 +++
top/maint.mk |2 +-
2
Hi Jim,
On 15 Nov 2011, at 18:14, Jim Meyering wrote:
Gary V. Vaughan wrote:
I think 'Copyright-paper-required: No' is still the best compromise here for
the reasons stated earlier in the thread.
Okay to push?
The FSF require that all non-trivial patches to its projects be
accompanied
Hi Jim,
On 15 Nov 2011, at 19:02, Jim Meyering wrote:
Gary V. Vaughan wrote:
On 15 Nov 2011, at 18:14, Jim Meyering wrote:
Gary V. Vaughan wrote:
I think 'Copyright-paper-required: No' is still the best compromise here
for
...
This is setting FSF policy,
Well, the policy is already set
Hi Jim,
On 15 Nov 2011, at 20:14, Jim Meyering wrote:
Gary V. Vaughan wrote:
Okay to push?
* top/maint.mk (tight-scope.mk): Make sure to prefix file
reference with $(srcdir) so that the file is found correctly even
when running `make syntax-check' in a VPATH build.
...
tight-scope.mk
Hi Jim,
On 15 Nov 2011, at 20:10, Jim Meyering wrote:
Gary V. Vaughan wrote:
On 15 Nov 2011, at 19:02, Jim Meyering wrote:
Propose a patch to maintain.texi.
I don't want to get into a debate over the merits of generated
ChangeLogs with RMS, which I already know he doesn't like.
I don't
Hi Jim,
Thanks for the reviews.
On 17 Nov 2011, at 03:01, Jim Meyering wrote:
Gary V. Vaughan wrote:
...
the parts that didn't work OOTB on my Mac to be portable. Feel free to crib
those portable parts of this one into coreutils, or reformat this one to
coreutils style as you prefer
not too far from now anyway):
http://git.savannah.gnu.org/cgit/libtool.git/plain/gl/build-aux/gitlog-to-changelog.diff
In the worst case, you might need to figure out what SHA1 revision of gnulib
libtool is using for its gnulib submodule, and use the same version.
HTH,
--
Gary V. Vaughan (gary
where the failing find
was invoked.
With gfind in my PATH, I also tried rerunning the testsuite with:
; FIND=gfind make check
...but I get the same failure.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Hi Peter,
On 28 May 2010, at 20:43, Peter O'Gorman wrote:
On 05/28/2010 12:30 AM, Gary V. Vaughan wrote:
Obviously, the test is assuming GNU find (which is called gfind on my
machine, but it doesn't come with Mac OS, which ships only BSD find),
but with a cursory look around I couldn't see
/priv.h
# endif
# endif
...
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
On 8 Jul 2010, at 21:55, Gary V. Vaughan wrote:
I guess the solution is to add checks for priv.h, sys/priv.h
headers and change priv-set.h to read as follows (or similar):
#if HAVE_GETPPRIV
# if HAVE_PRIV_H
# include priv.h
# else
# if HAVE_SYS_TYPES_H
# include sys
priv.h
This was already fixed by Paul Eggert on 2010-06-14.
Thanks for the heads up. I thought I was already running a day-or-three
old gnulib repo, but it appears not. Sorry for the noise.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
for the C++ compiler to complain about use of
templates inside `extern C'?
I have a workaround already (moving `#include sys/socket.h' outside the
`extern C'), but I'm curious about the real culprit, and maybe the gnulib
generated headers want to work properly when used like this?
Cheers,
--
Gary V
Hi Eric,
Thanks for the feedback.
On 23 Aug 2010, at 21:47, Eric Blake wrote:
On 08/22/2010 08:54 AM, Gary V. Vaughan wrote:
While trying to compile a C++ package, and using the gnulib socket modules
to paper over the differences between various vendor implementations, I
tripped over
that I can redefine to loop through the list of
directories.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
And theres more...
On 2 Sep 2010, at 23:36, Gary V. Vaughan wrote:
Is gnulib bootstrap designed for reuse in other projects?
I'm finding it extremely difficult to understand a lot of the code, let alone
incorporate it into Libtool. I have some fixes for the obvious bugs, and a
lot
Hi Jim,
Thanks for the feedback.
On 3 Sep 2010, at 13:05, Jim Meyering wrote:
Gary V. Vaughan wrote:
14. Updating
There's no obvious way for bootstrap to update itself. Since we got to some
lengths to install the `gnulib' subproject that it comes from, it should at
least
Hi Eric,
Thanks for your prompt response :) The fog is clearing a little already!
On 3 Sep 2010, at 01:01, Eric Blake wrote:
On 09/02/2010 10:36 AM, Gary V. Vaughan wrote:
Is gnulib bootstrap designed for reuse in other projects?
Yes; I know that it is already shared among coreutils, grep
On 3 Sep 2010, at 03:18, Jim Meyering wrote:
Gary V. Vaughan wrote:
1. gnulib_mk
# Name of the Makefile.am
gnulib_mk=gnulib.mk
What is this for? The only use in the rest of the script is inside the
slurp() function, who's purpose I cannot fathom:
if test $file
On 3 Sep 2010, at 17:03, Bruno Haible wrote:
Hi Gary,
Hallo Bruno,
Thanks for your comments.
Gary V. Vaughan wrote:
Is gnulib bootstrap designed for reuse in other projects?
I'm finding it extremely difficult to understand a lot of the code, ...
... a lot of questions about the design
in existing gnulib bootstrap using projects, slurp
can be removed?
I guess so, yes.
Excellent, that simplifies the rewritten bootstrap script considerably.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
On 6 Sep 2010, at 12:47, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Sep 06, 2010 at 05:20:30AM CEST:
On 6 Sep 2010, at 03:44, Ralf Wildenhues wrote:
Except that the autotools project logs contain lots of S-O-B entries
which explicitly do not have that particular meaning. :-/
I
using spinlocks without having tested for them first...
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Hi Paul,
Thanks for looking at this.
On 20 Sep 2010, at 13:21, Paul Eggert wrote:
On 09/19/2010 07:43 PM, Gary V. Vaughan wrote:
my system headers have no pthread_spinlock_t definition, but
gnulib sees /usr/include/pthread.h and uses that instead of generating it's
own,
...
I don't know
Hi Paul,
On 21 Sep 2010, at 00:30, Paul Eggert wrote:
On 09/20/10 00:14, Gary V. Vaughan wrote:
lib/pthread.h does have a typedef for pthread_spinlock_t, but it is
predicated on not having HAVE_PTHREAD_T defined (which I do):
Ah, OK. Could you try the following patch instead?
The patch
\
+ mv $...@-t $@
+MOSTLYCLEANFILES += pthread.h pthread.h-t
Include:
pthread.h
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
Hi Paul,
Thanks for the swift response.
On 22 Sep 2010, at 12:33, Paul Eggert wrote:
On 09/21/2010 10:11 PM, Gary V. Vaughan wrote:
But the patch causes a bizarre and apparently unrelated compilation
error:
; make V=1
gcc -std=gnu99 -I. -I../lib -g -O2 -MT sigprocmask.o -MD -MP
likely for builds to fail, and
perhaps preventing some runtime gotchas.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
OS X? :)
If that was directed at me, I wasn't paying enough attention to the rest
of the thread to know what that patch is... ;)
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
On 9 Oct 2010, at 04:56, Bruce Korb wrote:
Hey Gary,
Howdy Bruce,
(re-send -- I didn't see the first one show up on bug-gnulib list.)
Me neither.
On 09/26/08 20:34, Gary V. Vaughan wrote:
Long ago, far away and years ago, that is *precisely* the point I was
making. (Remember the autotool
On 9 Oct 2010, at 15:13, Ralf Wildenhues wrote:
Hello Gary,
Hallo Ralf,
* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 05:48:04AM CEST:
I had to autoreconf to get rid of a ton of spurious configure time errors
on my Mac... oddly, the first autoreconf threw up a ton of unset AC_LANG
Hi Bruno,
On Oct 10, 2010, at 2:12 AM, Bruno Haible br...@clisp.org wrote:
Gary V. Vaughan wrote:
I've never liked the gnulib 'non-release' policy, and think that maybe git
branching at some reasonably stable point from time to time and apply fixes
to make occasional libposix releases would
an AC_REQUIRE bug :(
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
On 10 Oct 2010, at 16:14, Gary V. Vaughan wrote:
2 bugs need fixing for this to work as intended:
D'oh. Make that 4. I kept editing the list, but forgot to update the sentence.
3. missing AM_CONDITIONAL declarations
--
I suppose the following definitions
in
the right order.
What's the difference between AC_USE_SYSTEM_EXTENSIONS and gl_USE_SYSTEM_
EXTENSIONS? The warnings seem to indicate that adding AC_REQUIRE([AC_
USE_SYSTEM_EXTENSIONS]) to AC_{RUN,COMPILE}_IFELSE is the right solution.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description
the scope of what I've got time for.
Managing library versioning is a difficult problem for any package. Such
a tool *would* be very useful for any package that ships non-trivial
libtool libraries. But it's a whole project unto itself as you say.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
On 10 Oct 2010, at 22:00, Bruce Korb wrote:
Hi Gary,
Hey Bruce!
On 10/10/10 02:14, Gary V. Vaughan wrote:
I think your script is *much* more complicated than it needs to be.
Of course it is. To properly understand 150+ lines of usage text
one needs to read the source and understand
Hi Bruno,
On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote:
It occurs to me also, that when another gnulib using project (that relies on
non-libposix modules) wants to minimise it's configury by requiring
libposix,
gnulib-tool will need an --avoid-posix option or similar so as not to end up
Hi Bruno,
On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote:
- You want to install the library, which can be done by specifying to
gnulib-tool a module (via --local-dir) which contains
lib_LTLIBRARIES = libposix.la
When gnulib-tool sees this declaration in a module, it will not emit
the configure.ac generated by the original
gnulib-tool invocation.
AC_USE_SYSTEM_EXTENSIONS right after AC_INIT can't fail to patch over
the bug, unless AC_REQUIRE ordering is badly botched.
I still maintain that this shouldn't be necessary.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
based versions, but since determining relative
stability of a release involves git and mailing-list archaeology anyway, I
really don't see terribly much advantage over a traditional release number.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
a mode to the libtool script to extract and display it.
No pkg-config tool required. No .pc files required. No PKG_CONFIG_PATH
required. Much much easier to use and maintain for all involved... pity
about all the man years wasted on pkg-config :(
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
PGP.sig
..d32d173 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-11 Gary V. Vaughan g...@gnu.org
+
+ Fix mismatched parens in previous commit
+ * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix
mismatched
+ parens.
+
2010-10-10 Paul Eggert egg...@cs.ucla.edu
101 - 200 of 302 matches
Mail list logo
