On Fri, 24 Apr 2020 at 02:41, Bruno Haible wrote:
>
> We do not want to put 'progname' under LGPL license, because 'progname' is
> meant to be used in programs, not libraries, and for programs the GPL is
> the right license.
>
That makes sense.
But things have changed since 2013: Gnulib modules
Hi Reuben,
> On Mon, 30 Dec 2013 at 09:28, Reuben Thomas wrote:
>
> > On 30 December 2013 08:18, Reuben Thomas wrote:
> >
> >>
> >> On 30 December 2013 01:20, Paul Eggert wrote:
> >>
> >>> Reuben Thomas wrote:
> >>>
> It's been drawn to my attention that under some circumstances, gnulib
>
On Mon, 30 Dec 2013 at 09:28, Reuben Thomas wrote:
> On 30 December 2013 08:18, Reuben Thomas wrote:
>
>>
>> On 30 December 2013 01:20, Paul Eggert wrote:
>>
>>> Reuben Thomas wrote:
>>>
It's been drawn to my attention that under some circumstances, gnulib
fails
to include progna
On 30 December 2013 08:18, Reuben Thomas wrote:
>
> On 30 December 2013 01:20, Paul Eggert wrote:
>
>> Reuben Thomas wrote:
>>
>>> It's been drawn to my attention that under some circumstances, gnulib
>>> fails
>>> to include progname when it's needed
>>>
>>
>> That's documented here:
>>
>>
>> h
On 30 December 2013 01:20, Paul Eggert wrote:
> Reuben Thomas wrote:
>
>> It's been drawn to my attention that under some circumstances, gnulib
>> fails
>> to include progname when it's needed
>>
>
> That's documented here:
>
> http://www.gnu.org/software/gnulib/manual/html_node/error-
> and-prog
Reuben Thomas wrote:
It's been drawn to my attention that under some circumstances, gnulib fails
to include progname when it's needed
That's documented here:
http://www.gnu.org/software/gnulib/manual/html_node/error-and-progname.html
According to Bruno Haible on 2/8/2010 4:41 PM:
> Ah, now I see. Yes, in this case HAVE_DECL_OBSTACK_PRINTF is not set to 0, and
> GNULIB_OBSTACK_PRINTF is not set to 1.
>
> So the combined proposed patch would look like this:
>
>
> 2010-02-08 Eric Blake
> Bruno Haible
>
>
Eric Blake wrote:
> But something IS needed. If you use gnulib-tool, but not --with-tests, then
> nothing calls gl_FUNC_OBSTACK_PRINTF, which means that
> HAVE_DECL_OBSTACK_PRINTF
> is never set to 0, which causes compilation failures on non-glibc platforms
> because obstack_printf is no longe
Bruno Haible clisp.org> writes:
> > * modules/obstack-printf-posix (Depends-on): Add obstack-printf.
>
> This is not needed. The modules 'obstack-printf-posix' and 'obstack-printf'
> are two modules that use the same source code but different .m4 macros.
> There is no need for running gl_FUN
Hi Eric,
> obstack-printf-posix-tests had a dependency on obstack-printf-tests.
> Somehow in the conversion to caching, we no longer pick up implicit
> dependencies of tests on their main module (that is, obstack-printf-tests no
> longer implies obstack-printf).
Wheee... You are right. This im
Eric Blake byu.net> writes:
>
> I will be committing this. Somehow, the recent gnulib-tool caching changes
> exposed it (the missing dependency is real; I'm not sure why the old gnulib-
> tool imported obstack-printf, but the current version is correct in avoiding
it
> without this patch).
Eric Blake wrote:
> It appears you forgot to commit this?
Yes. Done now.
> > Depends-on:
> > math
> > + fpucw
>
> And is there any reason you are undoing the alphabetic sort, other than that
> is
> what the file used to have before my patch?
Yes, keeping the natural order makes it easier
Bruno Haible clisp.org> writes:
> > * modules/printf-frexpl (Depends-on): Depend on ldexpl.
>
> Thanks for the quick fix. But this is overkill: the module 'ldexpl' looks
> for the ldexpl() function also in libm, and printf-frexpl doesn't this test
> result.
>
> 2007-04-03 Bruno Haible cl
Eric Blake wrote:
> libtool: compile: gcc -std=gnu99 -I. -I../../gnu -I../intl -g2 -Wall
> -Werror -MT ldexpl.lo -MD -MP -MF .deps/ldexpl.Tpo -c ../../gnu/ldexpl.c
> -DDLL_EXPORT -DPIC -o .libs/ldexpl.o
> ../../gnu/ldexpl.c:29:20: isnanl.h: No such file or directory
> ...
> make[3]: *** [ldexpl.lo
Eric Blake wrote:
> In trying to use sprintf-posix in m4, I came across this:
>
> cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
> configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS
> If this token and others are legitimate, please use m4_pattern
Hi Simon,
On 3 Apr 2007, at 11:22, Simon Josefsson wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
Please either, indent patches so that gpg doesn't escape leading '-'
signs, or use S/MIME for attaching as separate gpg signature.
I think you meant PGP/MIME (RFC3156), S/MIME doesn't use P
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> Please either, indent patches so that gpg doesn't escape leading '-'
> signs, or use S/MIME for attaching as separate gpg signature.
I think you meant PGP/MIME (RFC3156), S/MIME doesn't use PGP at all,
but yes, I agree with the suggesti
Hi Eric,
Please either, indent patches so that gpg doesn't escape leading '-'
signs,
or use S/MIME for attaching as separate gpg signature. Either would
allow
feeding a saved copy of emails containing a diff to GNU patch (which
copes
well with consistent indentation)
On 3 Apr 2007, at 04
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/2/2007 9:34 PM:
> In trying to use sprintf-posix in m4, I came across this:
>
> cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf
> configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WO
19 matches
Mail list logo
