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 enough about pthreads to tell whether gnulib should paper over
> the lack of spin
While testing my rewrite of gnulib's bootstrap script, I've been
unable to rebuild coreutils from git master. However, when I
reverted to a fresh checkout and used the repo bootstrap script,
the build still fails on my Mac:
../../src/sort.c:243: error: expected specifier-qualifier-list before
'p
Honestly, what is the problem with gnulib-tool? Why do you find it
hard to understand?
Personally, I think g-t is about as well written as anything of its size
and purpose could be, but 6000 lines of anything is not prima facie
obvious and easy to understand, regardless of language.
n
Hi Reuben,
> There seems to be some confusion about --aux-dir. gnulib --help says
> that its default value is "build-aux" ...
> On further investigation of gnulib-tool, this appears to be because it
> finds its value of auxdir from reading my configure.ac, which doesn't
> set a value, and hence de
After investigation, I think I found the bug: cut_dir should not be
hardwired to "/../", but rather set to "${top_srcdir}/". Otherwise, it
does not work for a typical in-tree build: cut_dir is not found in the
path, index returns 0, and an arbitrary few characters are cut off the
front of each file
1. The example Makefile.am code has "lib/" rather than "src/" in the
path to the source code, even though it's clearly the package source
that is to be analysed, not the gnulib library code.
2. In the generated report, all the filenames have the first character
of the path missing ("rc/" rather th
Another cool thing I just discovered in gnulib was pmccabe2html (and
that took a lot of googling).
I copied and pasted the example Makefile.am code into my Makefile.am,
and found a little nit in the process: the line starting "-v css" is
indented with spaces, not tabs as it should be for consisten
Are the mentions of GSS in the section "Out of memory handling" bogus
cut-and-paste-o's or similar? A bit of googling suggests that the text
has indeed been cut and pasted from the GNU GSS manual. It seems that
this section is essentially meant to document xalloc_die (not
xalloc_fail_func, which is
Hi Bruno,
On Sat, Sep 18, 2010 at 5:21 PM, Bruno Haible wrote:
>> "UNKNOWN-modified"? I don't know how you'd want to see that worked
>> into a version number.
>
> Hmm, for me that command prints
> 0.0.4280-882da
> Is your git version older than 1.6 ?
No. The script probably doesn't work becau
On 19 September 2010 14:33, Bruno Haible wrote:
Thanks for the explanation of --local-dir.
>> 2. There's a remark that is unclear to me: "(This kind of kitchen-sink
>> module is not needed when you
>> use the @command{gnulib-tool} option @samp{--makefile-name}.)" How
>> does --makefile-name help
Hello Reuben,
> Some questions, having read the documentation:
>
> 1. There doesn't seem to be a default value for --local-dir. I used
> local-lib; is there a recommended value?
I use --local-dir=gnulib-local; others use --local-dir=gl/override or
--local-dir=gl.
> It would be nice to have a de
On 15 September 2010 02:54:45 UTC+1, Bruno Haible wrote:
>> > Why can't you instead add \ escaping to all existing regex
>> > meta-characters
>> > that occur in the string, at which point you get the same effect without
>> > a
>> > new flag?
>>
>> Because that is error-prone (in particular, I woul
These \n's were appearing in diagnostics.
Here's the fix:
>From 882da58ae6f34b4637240739ae37a1b5efd39cf6 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 18 Sep 2010 21:26:27 +0200
Subject: [PATCH] maint.mk: avoid unexpanded \n in two diagnostics
* top/maint.mk (sc_prohibit_always_true_hea
13 matches
Mail list logo
