On 11 Jan 2012, at 12:59, Werner LEMBERG wrote:
>> Since then, I've broken out some functionality into reusable
>> standalone scripts that will be useful for replacing the hairy
>> sed-and-grep method of interrogating the m4 macros used by
>> configure.ac with a much more robust and faster call to
Bruno Haible wrote:
> Here's a proposed series of tweaks and alignments to the 'acl' and 'copy-file'
> modules, to make Reuben's proposed change to 'copy-file' easier.
>
> The first change is not backward compatible, but the only users of copy_acl()
> are coreutils and 'copy-file' in gnulib, and I'
> Since then, I've broken out some functionality into reusable
> standalone scripts that will be useful for replacing the hairy
> sed-and-grep method of interrogating the m4 macros used by
> configure.ac with a much more robust and faster call to parse the m4
> macros with GNU M4!
Parsing m4 macro
Hi Werner,
On 11 Jan 2012, at 12:30, Werner LEMBERG wrote:
After doing the incantation described in section 2.8 of gnulib.pdf,
namely
$ dir=.gnulib
$ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
the user has to commit the submodule setup to the r
>>> After doing the incantation described in section 2.8 of gnulib.pdf,
>>> namely
>>>
>>> $ dir=.gnulib
>>> $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>>>
>>> the user has to commit the submodule setup to the repository. It's
>>> probably worth to mention this.
>>>
>>> Howev
Hi Reuben,
> >> Is there no way to deal with error messages normally, i.e. via
> >> gnulib's strerror? Then the error-returning copy_file_preserving could
> >> replace the aborting version, and users who want to could check the
> >> return code and issue errors in the usual way.
> >
> > This would
Here's a proposed series of tweaks and alignments to the 'acl' and 'copy-file'
modules, to make Reuben's proposed change to 'copy-file' easier.
The first change is not backward compatible, but the only users of copy_acl()
are coreutils and 'copy-file' in gnulib, and I've verified that these caller
On 11 January 2012 00:28, Bruno Haible wrote:
>
> - But actually the function copy_file_preserving_error is equivalent to
> _copy_file_preserving. So why not just rename _copy_file_preserving
> to copy_file_preserving_error and ditch the one-line wrapper?
Done.
> - About the naming of the func
Hi Reuben,
Thanks for working on this refactoring.
Reuben Thomas wrote:
> Here's a revised version of my patch.
A couple of comments. Yes I heard that it's not so much fun to hear picky
comments, but quality...
- The function _copy_file_preserving is not declared nor used outside
that file. H
While compiling recutils-1.4.91 on MSVC 9, I got a link error due to the use
of function wctype(). This patch should fix it.
2012-01-10 Bruno Haible
regex: Avoid link error on MSVC 9.
* modules/regex (Depends-on): Add wctype.
--- modules/regex.orig Tue Jan 10 22:26:10 2012
+
On 01/10/2012 12:30 PM, Werner LEMBERG wrote:
>
>> After doing the incantation described in section 2.8 of gnulib.pdf,
>> namely
>>
>> $ dir=.gnulib
>> $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>>
>> the user has to commit the submodule setup to the repository. It's
>> proba
On 10 January 2012 20:24, Jim Meyering wrote:
>
> Just to be clear, sending a bug report is already great.
> If you think you'll find time to fix it later and say so,
> (esp. for documentation changes like this), we'll often be
> very happy to wait for a patch.
OK. Thanks very much to Bruno for t
Jim Meyering wrote:
>> So, is there a way I can simply file a bug report without a guilty
>> conscience? Note that that can mean "a bug report for which I later
>> provide a match", just as likely as "a bug report that gets added to
>
> Sure. No problem at all. Just say that you'll send a patch b
Reuben Thomas wrote:
> On 10 January 2012 18:14, Reuben Thomas wrote:
>>>
>>> It is good practice when asking for help (and getting it)
>>> to volunteer the patch that would have saved you some trouble.
>>> Since you've just hit a particular problem you are perhaps better
>>> placed than anyone el
Hi Reuben,
You did it just the right way: You sent a mail to bug-gnulib with
complete, reproducible experiments.
> You've hit the a particular problem I have here: sometimes when I'm
> deep in the middle of something else I just want to report a bug and
> move on
Yes, that should always be possi
> Perhaps you could try my rewrite of the bootstrap script, with which
> I cannot reproduce the problem you describe?
Will do that eventually, thanks.
> I'm unsure how to proceed. On one hand, I like `.gnulib' as the
> submodule's directory. On the other hand, I don't like `.gnulib' as
> the s
Eric Blake wrote:
> Personally, I use:
>
> ./gnulib-tool --with-tests --test copy-file
>
> which says to include the copy-file-tests module automatically, as well
> as running the unit test (and clean it up on success), when developing
> on a single machine. And when trying to test on a machine
Reuben Thomas wrote:
> Oh wait…
>
> ./gnulib-tool --test --dir=/tmp/testdir --with-tests copy-file-tests
>
> seems to do what I want! Still, this is not exactly obvious.
Hope this patch will make it a little bit more obvious.
2012-01-10 Bruno Haible
doc: Mention --with-tests option
Here's a revised version of my patch.
Is there no way to deal with error messages normally, i.e. via
gnulib's strerror? Then the error-returning copy_file_preserving could
replace the aborting version, and users who want to could check the
return code and issue errors in the usual way.
If that's
On 10 January 2012 19:38, Bruno Haible wrote:
>
> I need these URLs occasionally. For example, when I want to see what
> parameterization various packages use for the 'diffseq' module. Or
> which version of 'bootstrap' they use. Or similar things.
That's fine, since they have a value. That explai
Hello Reuben,
> Patch attached.
Thanks, applied.
> Are we seriously going to maintain URLs for all these
> projects? Isn't it better to delete them and rely on search engines to
> find them?
I need these URLs occasionally. For example, when I want to see what
parameterization various packages u
> After doing the incantation described in section 2.8 of gnulib.pdf,
> namely
>
> $ dir=.gnulib
> $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>
> the user has to commit the submodule setup to the repository. It's
> probably worth to mention this.
>
> However, if I now say
On 10 January 2012 18:14, Reuben Thomas wrote:
>>
>> It is good practice when asking for help (and getting it)
>> to volunteer the patch that would have saved you some trouble.
>> Since you've just hit a particular problem you are perhaps better
>> placed than anyone else to propose a fix.
You've
Hi Werner,
On 11 Jan 2012, at 01:40, Werner LEMBERG wrote:
>>> . First of all, there is some user-unfriendliness: Without
>>> installing a gnulib submodule for project `foo', just invoking
>>> the `bootstrap' script in the `foo' directory' without any
>>> arguments gives
>>>
>>>./bootstrap
On 10 January 2012 16:10, Eric Blake wrote:
> On 01/10/2012 08:56 AM, Reuben Thomas wrote:
>> Since users.txt is a human-readable file written in English, would it
>> be OK to reorder the projects in lexicographical rather than ASCII
>> order? I'm happy to write the patch if so. The fact that ther
>> . First of all, there is some user-unfriendliness: Without
>> installing a gnulib submodule for project `foo', just invoking
>> the `bootstrap' script in the `foo' directory' without any
>> arguments gives
>>
>> ./bootstrap: line 610: gnulib/gnulib-tool: No such file or directory
>>
On 10 January 2012 09:16, Jim Meyering wrote:
> A couple of suggestions:
Thanks for the review.
> ERR_READ may be too generic, risking collision with symbols defined by
> other applications. Perhaps names like GL_COPY_READ_FAILURE,
> GL_ACL_PRESERVE_FAILURE, etc.
I now have GL_COPY_ERR_*. I
On 10 January 2012 18:07, Jim Meyering wrote:
>
> It is good practice when asking for help (and getting it)
> to volunteer the patch that would have saved you some trouble.
> Since you've just hit a particular problem you are perhaps better
> placed than anyone else to propose a fix.
You're quite
Reuben Thomas wrote:
> On 10 January 2012 16:58, Eric Blake wrote:
>>
>> Yes, --dir is optional if you don't specify --create-testdir.
>
> Right, so could you please fix the documentation accordingly?
Hi Reuben,
It is good practice when asking for help (and getting it)
to volunteer the patch tha
On 10 January 2012 16:58, Eric Blake wrote:
>
> Yes, --dir is optional if you don't specify --create-testdir.
Right, so could you please fix the documentation accordingly?
Correcting the help of gnulib-tool seems to be sufficient, since the
--test option is not documented in the manual (at least,
On 01/10/2012 09:55 AM, Reuben Thomas wrote:
>> That says where the test dir should be located, but didn't load any test
>> modules to actually do the testing. Personally, I use:
>>
>> ./gnulib-tool --with-tests --test copy-file
>>
>> which says to include the copy-file-tests module automatically,
On 10 January 2012 16:51, Eric Blake wrote:
> On 01/10/2012 09:30 AM, Reuben Thomas wrote:
>> I've just spent a while trying to work out how to run tests for a
>> particular module, and I'm not getting very far.
>>
>> ./gnulib-tool --help brings up the "--test" mode, which looks
>> promising, but
On 01/10/2012 09:30 AM, Reuben Thomas wrote:
> I've just spent a while trying to work out how to run tests for a
> particular module, and I'm not getting very far.
>
> ./gnulib-tool --help brings up the "--test" mode, which looks
> promising, but if I run
>
> ./gnulib-tool --test --test-dir=/tmp/
The sense of the offending sentence was reversed.
I.e., we print the names of bad files, not those of conforming ones.
>From f9813bce2c06a6130a68db4478d1b16ddadaf276 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 10 Jan 2012 17:32:32 +0100
Subject: [PATCH] maint.mk: fix description in com
I've just spent a while trying to work out how to run tests for a
particular module, and I'm not getting very far.
./gnulib-tool --help brings up the "--test" mode, which looks
promising, but if I run
./gnulib-tool --test --test-dir=/tmp/testdir copy-file
then that only seems to build copy-file,
On 01/10/2012 08:56 AM, Reuben Thomas wrote:
> Since users.txt is a human-readable file written in English, would it
> be OK to reorder the projects in lexicographical rather than ASCII
> order? I'm happy to write the patch if so. The fact that there are
> only 3 projects out of order makes it a mi
Since users.txt is a human-readable file written in English, would it
be OK to reorder the projects in lexicographical rather than ASCII
order? I'm happy to write the patch if so. The fact that there are
only 3 projects out of order makes it a minor irritation.
--
http://rrt.sc3d.org
On 01/10/2012 08:20 AM, Werner LEMBERG wrote:
>
> [gnulib 530dd174]
>
>
> The `git submodule' is a very nice feature, however, there are two
> issues.
>
> . First of all, there is some user-unfriendliness: Without
> installing a gnulib submodule for project `foo', just invoking the
>
[gnulib 530dd174]
The `git submodule' is a very nice feature, however, there are two
issues.
. First of all, there is some user-unfriendliness: Without
installing a gnulib submodule for project `foo', just invoking the
`bootstrap' script in the `foo' directory' without any arguments
Reuben Thomas wrote:
> Ping! I've not heard anything about this; my current patch (as used in
> GNU Zile) still seems to work.
Hi Reuben,
Thanks for the reminder.
A couple of suggestions:
ERR_READ may be too generic, risking collision with symbols defined by
other applications. Perhaps name
Christian Grothoff wrote:
> Just FYI, amatus (the reporter) now writes: "Nevermind. I got confused." and
> marked the bug as resolved...
Thanks for letting us know.
41 matches
Mail list logo
