Jim Meyering wrote:
> > Would it help to have an option for gnulib-tool that avoids running
> > configure, knowing that it will be run afterwards anyway? Currently
> > gnulib-tool invokes configure and make for generating distributed
> > built files (i.e. running bison, gperf, or similar unusual to
Jim Meyering wrote:
> > Gnulib's DEPENDENCIES says 1.9.6 or later is ok. What features of newer
> > automake releases are required by gnulib?
>
> Hard to tell without having diagnosed his problem. Maybe none.
> IMHO, automake-1.9.6 is not just a little bit too old,
> but prohibitively old, now.
Bruno Haible wrote:
...
> Would it help to have an option for gnulib-tool that avoids running
> configure, knowing that it will be run afterwards anyway? Currently
> gnulib-tool invokes configure and make for generating distributed
> built files (i.e. running bison, gperf, or similar unusual tools)
Thomas Guyot-Sionnest wrote:
> >> autoconf (GNU Autoconf) 2.61
> >> automake (GNU automake) 1.9.6
>
> This is what originally tipped me:
> ./build-aux/po/Makefile.in.in:39:# In automake >= 1.10, @mkdir_p@ is
> derived from ${MKDIR_P}, which is defined
This is a red herring. What changed in automa
Ralf Wildenhues wrote:
> > But for things like @LIBINTL@
> > and @LIBSOCKET@, it is still better to write them as @LIBINTL@, not
> > $(LIBINTL),
> > because if the corresponding autoconf macro was not run, it makes the error
> > appear on all platforms. Otherwise it's too easy to write a Makefile.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 10/4/2009 5:24 AM:
> Right, but the solution assumes that people building my software from
> version controlled sources has installed the same version of gnulib that
> was used when my software was committed to the repos
Simon Josefsson wrote:
> Right, but the solution assumes that people building my software from
> version controlled sources has installed the same version of gnulib that
> was used when my software was committed to the repository. I don't
> think that is reliable in the long run, or rather, it is
Bruno Haible writes:
> Simon Josefsson wrote on 2009-08-31:
>> > Until then, you have to overwrite autopoint'ed files with copies brought in
>> > by gnulib-tool.
>>
>> Is this still the recommended practice for using autopoint and
>> gnulib-tool together?
>>
>> I ran into an issue where size_max
Simon Josefsson wrote on 2009-08-31:
> > Until then, you have to overwrite autopoint'ed files with copies brought in
> > by gnulib-tool.
>
> Is this still the recommended practice for using autopoint and
> gnulib-tool together?
>
> I ran into an issue where size_max.m4 imported by autopoint was ol
On 10/04/2009 11:45 AM, Bruno Haible wrote:
Now, looking at the two sides of this patch, honestly I don't find the latter
side more readable. The first code is immediately, it's clear what it does.
For the second code I find myself asking:
"What if the loop over i falls off the end of the arra
Jim Meyering wrote on 2009-08-25:
> No. That package *does* use the error module.
> However, per m4/error.m4, when building on a glibc-based system,
> error.c is not compiled.
>
> Your addition to this comment made it misleading:
>
> /* On glibc systems, when the gnulib module 'error' is not u
Paolo Bonzini wrote:
> * lib/uname.c: Handle Windows CE and its processor types. Remove
> code for processors never supported by Windows 95/98/ME. Rewrite
> conversion of NT version numbers to product names.
The large part, the rewrite of the NT version numbers conversion,
looks like this after
Eric Blake writes:
> According to Simon Josefsson on 9/23/2009 12:21 PM:
>> fseek.c:26: error: expected declaration specifiers or '...' before '(' token
>> fseek.c:27: error: conflicting types for 'rpl_fseeko'
>> ./stdio.h:258: error: previous declaration of 'rpl_fseeko' was here
>
> I see the pr
13 matches
Mail list logo
