Charles Wilson wrote:
The file lib/progreloc.c has no module, and carries an embedded GPL
license. However, the intent for this file is that it is LGPL,
according to the check-in message for revision 1.5, here:
http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/lib/progreloc.c?rev=1.10&view=lo
Hello Paul, Bruno,
* Paul Eggert wrote on Wed, Nov 15, 2006 at 09:54:19PM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > The allocsa.m4 change contradicts
> > http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html
>
> I don't see why it's contradictory.
* Bruno Haible wrot
Karl Berry wrote:
> gnulib-tool says you "may" need to include:
> #include
> #include
> #include
> #include "__fpending.h"
> #include "close-stream.h"
> #include "closeout.h"
> #include "error.h"
> #include "exit.h"
> #include "exitfail.h"
> #include "gettext.h"
> #include
Ralf Wildenhues wrote:
> The allocsa.m4 change contradicts
> http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html
The URL is very relevant (I was tempted to use AC_REQUIRE, nearly falling
into the pitfall again), thanks. But I don't actually see the contradiction.
Bruno
[EMAIL PROTECTED] (Karl Berry) writes:
> Would it be reasonable/possible to have gnulib-tool output only the
> top-level #includes?
Yes, that makes sense.
Jim Meyering <[EMAIL PROTECTED]> writes:
> #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1)
That sounds reasonable to me, as a workaround.
Eric Blake wrote:
> --- m4/alloca.m4 20 Oct 2006 13:50:26 - 1.8
> +++ m4/alloca.m4 15 Nov 2006 17:00:14 -
> @@ -1,4 +1,4 @@
> -# alloca.m4 serial 6
> +# alloca.m4 serial 7
> dnl Copyright (C) 2002-2004, 2006 Free Software Foundation, Inc.
> dnl This file is free software; t
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> The allocsa.m4 change
> contradicts
> http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html
I don't see why it's contradictory. That URL says that gl_ALLOCSA
should not AC_REQUIRE gl_FUNC_ALLOCA. But the proposed allocsa.m4
change:
>>
Eric Blake wrote:
> 2006-11-15 Eric Blake <[EMAIL PROTECTED]>
>
> * m4/allocsa.m4 (gl_ALLOCSA): Don't invoke macro already picked
> up by the module dependency.
>
> Index: m4/allocsa.m4
> ===
> RCS file: /sources/gnulib
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
>
>> warning: getaddrinfo is LGPL but depend on intprops which is GPL
>> warning: inttostr is LGPL but depend on intprops which is GPL
>
> Jim, Paul, is it possible to have intprops be under LGPL? The
> a
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> warning: getaddrinfo is LGPL but depend on intprops which is GPL
> warning: inttostr is LGPL but depend on intprops which is GPL
Jim, Paul, is it possible to have intprops be under LGPL? The
alternative solution I see is to revert the patch for
Paul Eggert <[EMAIL PROTECTED]> writes:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
>
>> warning: argp is LGPL but depend on exitfail which is GPL
>> warning: canon-host is LGPL but depend on intprops which is GPL
>> warning: euidaccess is LGPL but depend on exitfail which is GPL
>> warning
Yoann Vandoorselaere wrote:
> > Yes, I agree. Do you have time to add such a test to gnulib-tool's
> > func_create_testdir?
>
> Patch attached (note: I'm not very good at shell programming).
Thanks, I fixed the obvious mistake in it (it overwrote the $modules
variable), turned the fatal error int
Hello Eric,
* Eric Blake wrote on Wed, Nov 15, 2006 at 06:02:00PM CET:
>
> checking for intmax_t... (cached) yes
> (cached) (cached) checking whether to enable assertions... no
>
> I tracked both of those spurious messages to this. gl_ALLOCSA was calling
> gl_FUNC_ALLOCA rather than AC_REQUIRE
I made another pretest of hello, ftp://alpha.gnu.org/gnu/hello. The
only changes are the ones reported here.
When running gnulib-tool --import or --update, there is quite a
long list of #include's. The only modules I've actually specified are
closeout getopt gettext. I imagine that many of the
Paul Eggert CS.UCLA.EDU> writes:
> > 2006-11-15 Eric Blake byu.net>
> >
> > * m4/alloca.m4 (gl_FUNC_ALLOCA): Use AC_CACHE_CHECK to avoid a
> > random "(cached)" in configure output.
> > * m4/allocsa.m4 (gl_ALLOCSA): Don't invoke macro already picked
> > up by the module depende
Eric Blake <[EMAIL PROTECTED]> writes:
> OK to install?
>
> 2006-11-15 Eric Blake <[EMAIL PROTECTED]>
>
> * m4/alloca.m4 (gl_FUNC_ALLOCA): Use AC_CACHE_CHECK to avoid a
> random "(cached)" in configure output.
> * m4/allocsa.m4 (gl_ALLOCSA): Don't invoke macro already picked
>
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> warning: argp is LGPL but depend on exitfail which is GPL
> warning: canon-host is LGPL but depend on intprops which is GPL
> warning: euidaccess is LGPL but depend on exitfail which is GPL
> warning: fts-lgpl is LGPL but depend on exitfail which
Currently, when rerunning the m4 configure script with caching enabled, this
output is appearing:
checking for intmax_t... (cached) yes
(cached) (cached) checking whether to enable assertions... no
I tracked both of those spurious messages to this. gl_ALLOCSA was calling
gl_FUNC_ALLOCA rather
Ralf Wildenhues wrote:
> I did that, but IMHO it's a bit inconsistent:
> $ echo 2> &1
> | bash: syntax error near unexpected token `&'
'>&' is an operator on its own, and '2>&1' is an idiom that doesn't require
spaces to be understandable.
Bruno
On Tue, 2006-11-14 at 09:53 -0800, Paul Eggert wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
> > inttostr.c is barely 20 lines of code, and pretty simple.
> > And each of the other .c files is just a 3-line stub.
> > Changing the module to LGPL is fine with me, but Paul's the owner.
>
> I
21 matches
Mail list logo
