Re: Can't build libposix

Hi Reuben, On 8 Dec 2010, at 05:32, Reuben Thomas wrote: > From a current checkout from git, I get, from make: > > make[3]: *** No rule to make target `version.lo', needed by > `libposix.la'. Stop. > > I have followed the bootstrapping instructions I found on the list > (./bootstrap; ./configur

Re: libposix nit

Reuben Thomas wrote: > configure does not complain if gperf is not installed. This is normal. 'gperf' is generally not among the tools that a user needs when configuring from a distributed tarball. It is the responsibility of whoever creates that tarball (e.g. via "make dist") to run gperf on the

Can't build libposix

>From a current checkout from git, I get, from make: make[3]: *** No rule to make target `version.lo', needed by `libposix.la'. Stop. I have followed the bootstrapping instructions I found on the list (./bootstrap; ./configure; make)... Help please? -- http://rrt.sc3d.org

libposix nit

configure does not complain if gperf is not installed. -- http://rrt.sc3d.org

Re: unistr use of undefined macros

On 12/07/2010 02:24 PM, Ludovic Courtès wrote: > Hello, > > Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a > side-effect, this prevents compilation of users of this file, such as > Guile, with ‘-Wundef’: Unfortunately, that points to a bug in guile. Gnulib is explicitly documented

unistr use of undefined macros

Hello, Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a side-effect, this prevents compilation of users of this file, such as Guile, with ‘-Wundef’: --8<---cut here---start->8--- In file included from bytevectors.c:43:0: ../lib/unistr.h:161:5: erro

Re: nproc -> LGPL

Bruno Haible writes: > Glen Lenker wrote: >> > Glen, do you also agree with Ludo's request? >> >> It is fine with me; nproc is quite libraryish. > > OK, I've pushed the license change. Great, thanks! Ludo’.

Re: more problems with --create-testdir and --add-import

> The differences between --create-testdir and --add-import are > explained by their different use cases. [...] > > --create-testdir create a scratch package with the given modules Mhmm, I had no idea what `scratch package' really means. To do something `from scratch' normally means to st

Re: --create-testdir ignores --source-base and --m4-base

Hello Werner, > The title says all. I consider this a serious bug. There is no need to have --create-testdir obey --source-base and --m4-base because it wouldn't help portability checking. The "gnulib-tool --help" output is clear about the fact that --source-base and --m4-base apply only to --i

Re: more problems with --create-testdir and --add-import

Hello Werner, The differences between --create-testdir and --add-import are explained by their different use cases. The --help text gives a brief summary already: --import import the given modules into the current package --add-import augment the list of imports

more problems with --create-testdir and --add-import

[gnulib commit 64911207] Comparing the contents of the gnulib directory created by gnulib-tool --create-testdir \ --dir=src/libs/gl \ wcwidth and gnulib-tool --add-import \ --dir=src/libs/gl \ --source-base=gllib \ --m4-

--create-testdir ignores --source-base and --m4-base

[git 64911207] The title says all. I consider this a serious bug. Werner

--create-testdir and --add-import don't harmonize

[gnulib commit 64911207] Doing gnulib-tool --create-testdir --dir=src/libs/gl wcwidth creates the following directory structure: src/libs/gl/build-aux src/libs/gl/gllib src/libs/gl/glm4 However, doing gnulib-tool --add-import --dir=src/libs/gl wcwidth afterwards, I have two new di