Hi Gary,
On 10/12/10 09:08, Gary V. Vaughan wrote:
> +++ b/libposix/bootstrap
> @@ -0,0 +1,55 @@
> +#! /bin/sh
> +
> +PATH=..:$PATH
> +
> +gnulib-tool --import --lib=libposix --makefile-name=gnulib.mk \
> + --macro-prefix=LIBPOSIX --libtool --no-changelog --symlink \
> + --with-tests --with-c++
Gary V. Vaughan wrote:
> git-version-gen itself relies on the presence of .git in the
> current directory. I've made a quick and dirty patch to it
> here to also look in the parent directory... but surely there's
> a nicer way to determine whether the current directory is managed
> by git than thi
On 10/12/2010 03:03 PM, Ralf Wildenhues wrote:
It took me two years to realize that branched development is really
adding substantial value to development. I really wouldn't want to go
back now.
FWIW, I'm still working on several projects that like linear development
(coreutils, gnulib, m4, l
Hello Bruno, all,
* Bruno Haible wrote on Tue, Oct 12, 2010 at 10:03:09PM CEST:
> There's also a technical problem: Jim decided that in gnulib's git repository,
> merge commits are disallowed. I don't remeember the rationale, but I think it
> is a good decision, because
> 1. it assigns a clear r
Hi Gary,
> * libposix/bootstrap: New script to import gnulib posix modules
> and bootstrap configury so that the result is an installable
> libposix.la.
> * libposix/configure.ac: New file to configure the new libposix
> subdirectory.
> * libposix/Makefile.am: New file to delegate build duties to
Hi Gary,
> Originally, I added noinst_HEADERS to the module definition files,
> and then changed them all to nobase_nodist_include_HEADERS and
> EXTRA_HEADERS in gnulib-tool if the gnulib library is installable.
> However, I think it is much more flexible to add the
> 'nodist_include_HEADERS' or '
Hi Gary,
> Making libposix into a module makes life considerably easier.
Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of
noinst_LIBRARIES.
But I don't agree with putting the module list here. Who will keep it
up-to-date? The maintainable solution is to use `./posix-
Hi Gary,
> * gnulib-tool (func_emit_lib_Makefile_am): transform hard-coded
> `libgnu.a' in Makefile.am snippets to be either `$libname.a' or
> `$libname.la', depending on whether --libtool/--no-libtool options
> were given.
Here it's clear that we need a way to combine the module description
of '
Hi Gary,
> By itself, this patch reduces unnecessary repetition, but also sets up
> a later patch in this series to not need to make yet another copy of
> the listed headers.
>
> * modules/iconv_open (iconv_headers): New make macro to hold list of
> iconv header files.
> (BUILT_SOURCES, MAINTAINE
Hi Gary,
> This patch series is what I've just pushed as a new topic branch to
> the savannah repo.
Wow! You're fast. I love your initiative and appreciate your approach.
> Okay to merge to master?
Not so fast. We need to digest and check each of the patches one by one.
There's also a technica
On 10/11/10 18:21, Gary V. Vaughan wrote:
> As I've tweaked it to support existing users, I've found that some
> of them (bison and tar, I'm looking at you!) don't even use the
> canonical version.
That's been fixed as of Oct 8 and Oct 11, respectively.
I'll try to take a look at the proposed boo
Hi Gary,
> * gnulib-tool (func_import): support multiple gllib directories:
> headers are generated for each gllib differently, depending on which
> features are actually used, so we need to be able to include all
> these generated headers without fear that one will shadow another,
> so we prepend
Hi Bruce, Gary,
Bruce Korb wrote:
> KISS: once you've included a gnulib mumble.h, all other
> gnulib mumble.h-es are noop-ed.
Nope. We cannot do this, we don't want this. It would mean that every gnulib-
derived file would provide the same macros and functions. This is
not compatible with gnuli
Hi Gary,
> Then I believe the only viable option to provide stable support for
> multiple gnulib directories in a single tree is to add a switch to
> gnulib-tool to rewrite gnulib #include_next lines on import, so that
> both types of compilers include header files in the same order.
Thanks for t
From: Sam Steingold
This is based on:
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?revision=1.1&view=markup
But doesn't have any of the problems I outlined earlier today.
Although I've committed on topic/libposix branch for testing, I think
it can be safely merged to m
By itself, this patch reduces unnecessary repetition, but also sets up
a later patch in this series to not need to make yet another copy of
the listed headers.
* modules/iconv_open (iconv_headers): New make macro to hold list of
iconv header files.
(BUILT_SOURCES, MAINTAINERCLEANFILES, EXTRA_DIST)
This fixes the problem outlined in point 4 of this email:
http://www.mail-archive.com/bug-gnulib@gnu.org/msg20010.html
It too could be merged independently of the branch, but from here on in
I've only tested the branch in its entirety.
* gnulib-tool (func_emit_lib_Makefile_am): transform har
Originally, I added noinst_HEADERS to the module definition files,
and then changed them all to nobase_nodist_include_HEADERS and
EXTRA_HEADERS in gnulib-tool if the gnulib library is installable.
However, I think it is much more flexible to add the
'nodist_include_HEADERS' or 'nobase_nodist_includ
Making libposix into a module makes life considerably easier. Later in the
series, the libposix bootstrap script performs a sanity check to determine
whether this module's dependencies are still in sync with the output of
posix-modules.
The alternative is to feed the output of posix-modules to se
Might as well use the existing git-version-gen mechanism to
get git based unique version strings for libposix. However,
git-version-gen itself relies on the presence of .git in the
current directory. I've made a quick and dirty patch to it
here to also look in the parent directory... but surely t
This patch series is what I've just pushed as a new topic branch to
the savannah repo.
Distcheck results by architecture and compiler:
dec Tru64 5.1 Compaq C 6.5 (mbrlen.c compile failed:
rpl_mbstate_t has no linkage and a prior
And with all the groundwork done, this patch creates a libposix
subdirectory with necessary files to bootstrap, configure, build,
test, install and distribute libposix from within.
Note the sanity check in bootstrap I mentioned earlier
* libposix/bootstrap: New script to import gnulib posix modul
22 matches
Mail list logo
