FYI,
minor --help fix:
>From a96bd790af86ef28fbd95f619e390713587e2d8d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 1 Sep 2009 08:49:27 +0200
Subject: [PATCH] announce-gen: correct formatting in --help output
* build-aux/announce-gen (usage): Move the one-line description in
--help out
Ralf Wildenhues wrote:
> * Bruno Haible wrote on Sun, Aug 30, 2009 at 11:30:53PM CEST:
>> > configure.ac:21: warning: The macro `AC_TRY_RUN' is obsolete.
>>
>> You can ignore these warnings. AC_TRY_RUN and AC_TRY_LINK cannot go away
>> because hundreds of autoconf macros use them.
>
> I'd venture t
Bruno Haible wrote:
> Jim Meyering wrote:
>> I've been lobbying to remove the obsolescent @VAR@ notation
>> in favor of $(VAR) notation for a long time.
> Using @VAR@ instead of $(VAR) removes one level of complexity, thus
> making debugging easier: If someone reports that in a Makefile,
> @FOO@ d
Hello Bruno,
* Bruno Haible wrote on Tue, Sep 01, 2009 at 01:03:41AM CEST:
>
> $(VAR) certainly adds a level of flexibility over @VAR@, but I find that
> rarely useful.
Still, the standards.texi authors found that additional flexibility so
useful that they explicitly document it as required for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/31/2009 3:35 PM:
> One of the main reasons the fchdir module was added was so that the openat
> module (and friends) would compile on mingw. Well, it turns out that mingw
> has
> the (documented) limitation that open(di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 8/31/2009 10:47 AM:
>> I will be pushing these later today as prerequisites to fixing fchdir and
>> splitting fdopendir into its own module. This series avoids some compilation
>> warnings due to missing chmod on mingw, an
Bruno Haible wrote:
> Ah, I see. The version that matters is the one of the GNU gettext macros that
> will be used.
...will be used *at program build time*.
> Therefore `gettext --version` is irrelevant; what matters is
> what 'aclocal' will fetch later. How would you like the notice to be
> formul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/31/2009 5:38 PM:
> Notice that this changes the status of fdopendir - whereas it was previously
> non-multithread safe and could call _exit, the mingw version of fdopendir is
> now threadsafe and avoids _exit.
Well, not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 8/31/2009 7:02 PM:
> I usually modify CC instead. I never tried for gnulib, but it would
> look like this:
>
> MINGW=$(cygpath -u '\mingw')
> export PATH=$MINGW/bin:$PATH
> ./configure --host=i586-pc-mingw32
On 09/01/2009 12:51 AM, Bruno Haible wrote:
Hi Simon,
Getting gnulib to build natively on Windows was a bit difficult
I built gnulib on Windows a dozen of times already. The configuration
that works best is from within a cygwin environment, with
PATH=/usr/local/mingw/bin:$PATH
export
Eric Blake byu.net> writes:
>
> Eric Blake byu.net> writes:
>
> > One improvement possible for fdopendir is that
> > if fchdir is being emulated by gnulib, we can do a query into the fchdir
> > metadata table to retrieve the directory name associated with an fd, rather
> > than having to go
Eric Blake byu.net> writes:
> One improvement possible for fdopendir is that
> if fchdir is being emulated by gnulib, we can do a query into the fchdir
> metadata table to retrieve the directory name associated with an fd, rather
> than having to go through save_cwd/fchdir/opendir/restore_cwd.
Jim Meyering wrote:
> I've been lobbying to remove the obsolescent @VAR@ notation
> in favor of $(VAR) notation for a long time.
Using @VAR@ instead of $(VAR) removes one level of complexity, thus
making debugging easier: If someone reports that in a Makefile,
@FOO@ does not expand to a correct va
Hi Simon,
> Getting gnulib to build natively on Windows was a bit difficult
I built gnulib on Windows a dozen of times already. The configuration
that works best is from within a cygwin environment, with
PATH=/usr/local/mingw/bin:$PATH
export PATH
./configure --host=i586-pc-mingw32 --pr
One of the main reasons the fchdir module was added was so that the openat
module (and friends) would compile on mingw. Well, it turns out that mingw has
the (documented) limitation that open(dir,O_RDONLY) fails with EACCES, so
rpl_open was never registering an fd visiting a directory in the fi
Hi Stefano,
> The bug is in this command:
> $CONFIG_SHELL -c 'echo '\t' | grep t > /dev/null'
> which should check if $CONFIG_SHELL (when set) has a usable `echo'
> command. But the way it's written, that test *always* succeds,
> even if $CONFIG_SHELL has a broken `echo' builtin. This is cause
Eric Blake wrote:
> I will be pushing these later today as prerequisites to fixing fchdir and
> splitting fdopendir into its own module. This series avoids some compilation
> warnings due to missing chmod on mingw, and allows me to run gnulib testsuites
> under cygwin while cross-compiling to ming
Simon Josefsson wrote:
> Getting gnulib to build natively on Windows was a bit difficult, "make"
> appears to break when trying to CreateProcess on /usr/bin/mkdir which
> doesn't exist as a binary. How about this patch? It allows users to
> specify the mkdir command when invoking 'make'.
>
> The
I will be pushing these later today as prerequisites to fixing fchdir and
splitting fdopendir into its own module. This series avoids some compilation
warnings due to missing chmod on mingw, and allows me to run gnulib testsuites
under cygwin while cross-compiling to mingw:
$ cross_compiling=y
FYI, there was a useless initialization in canonicalize_filename_mode.
[spotted by using clang: http://clang.llvm.org/StaticAnalysis.html]
This removes it:
>From 08999eb3be233d8c54c9fe00c5c263247265e897 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 31 Aug 2009 16:32:40 +0200
Subject: [PA
Getting gnulib to build natively on Windows was a bit difficult, "make"
appears to break when trying to CreateProcess on /usr/bin/mkdir which
doesn't exist as a binary. How about this patch? It allows users to
specify the mkdir command when invoking 'make'.
The patch seems generally to be the Ri
Hi everybody.
While skimming through the gnulib-tool source code, I spotted what
seems to be a minor bug in the code that looks for a "working"
`echo' command (i.e. an `echo' that doesn't interpret backslashes).
This is around line 700-710 in my copy of gnulib-tool, which should
be up-to-date w.r.
This works around a bug in the glibc 2.7 macro implementation of
strtok_r described here:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5614.
Usually my gnulib submissions are intended primarily to help GNU
PSPP. In this case, however, GNU PSPP doesn't actually trigger
the bug that this fixe
Bruno Haible writes:
>> The problem is that if mingw+wine doesn't work for me (as developer) I
>> won't be able to produce Windows package and feel confident that they
>> will work.
>
> You can also produce or test the Windows packages on real Windows, to get
> confidence, no?
Of course. So, ma
Bruno Haible writes:
>> Would this problem go away if gnulib's copy is updated?
>
> This problem will only go away when either the integration between
> gettextize and automake is improved (but this is stalled since apparently
> currently noone with automake skills seriously wants to work with me
[whoops. reposting to bug-gnulib, not bug-coreutils]
Hi Sergey,
In exclude.c, we have this:
bool
excluded_file_name (struct exclude const *ex, char const *f)
{
...
switch (seg->type)
{
case exclude_pattern:
rc = excluded_file_patt
Bruno Haible wrote:
> Pádraig Brady wrote:
>> I was wondering about this general issue a couple of days ago when pondering:
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2bc0f3c
>>
>> At the application level we often want to check for this
>> "not supported" condition while
Bruno Haible wrote:
> Pádraig Brady wrote:
>> I was wondering about this general issue a couple of days ago when pondering:
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2bc0f3c
>>
>> At the application level we often want to check for this
>> "not supported" condition whil
28 matches
Mail list logo
