Hi Bruno,
> gnulib-tool offers you a way to adapt the Gnulib source to your wishes:
> If you store a file lib/md5.c.diff in a subdirectory 'gnulib-local' of
> your package and pass the option --local-dir=gnulib-local to the gnulib-tool
> invocation, gnulib-tool will apply this diff when pullin
Eric Blake wrote:
> Johan, can you find the portion in config.log that shows whether the
> native posix_spawn was deemed acceptable or buggy?
It looks acceptable:
checking for posix_spawn... yes
checking whether posix_spawn works... yes
checking whether posix_spawn is declared without a macro.
What I mean - I wouldn't mind commiting gnulib stuff to VCS, but only
if I can omit files generated by autoreconf.
FWIW, that is exactly what I do for Texinfo. It helps my contributors
to not spend time dealing with gnulib, and it helps me because it avoids
gnulib-skew differences between
On 3/1/10, Simon Josefsson wrote:
>
> It would be nice it gnulib-tool could do it, but I have a hard time
> thinking how that would actually be implemented. There are so many
> different ways you may want to organize your gnulib directories that
> having gnulib-tool support them all is probabl
Sam Steingold writes:
> On 3/1/10, Simon Josefsson wrote:
>>
>> On my debian system,
>
> how about the poor souls stuck with non-kosher fedora? :-)
You are in the same boat as I compared to those gNewSense users. ;-)
>> Further, these functions seems rather independent of other
>> system-re
On 3/1/10, Simon Josefsson wrote:
>
> On my debian system,
how about the poor souls stuck with non-kosher fedora? :-)
> Further, these functions seems rather independent of other
> system-replacing functionality, so couldn't you put them in a separate
> "global" directory and let all your su
Sam Steingold writes:
>> systems. Did you try to measure the bloat size? Which modules with
>> object code do you need in every sub-module?
>
> here is what I pass with --avoid:
>
> no-c++ stdint stdbool havelib gettext localcharset
> uniwidth/width streq uniname/uniname unitypes link-follow
Peter Simons wrote:
> I completely agree that Gnulib shouldn't try to support
> non-config.h builds in general. It's not worth the effort, really. Yet,
> at the same time it would feel like prudent software engineering if
> Gnulib would avoid creating unnecessary obstacles for those projects
> that
[adding bug-gnulib]
According to Johan van Selst on 3/1/2010 2:55 PM:
> Eric Blake wrote:
>> According to Johan van Selst on 3/1/2010 11:02 AM:
>>> Sure, it's now up on http://mud.stack.nl/~johans/193-ktrace.txt
>>> (output from the test in checks/193.esyscmd)
>> Actually, it looks like you posted
On 3/1/10, Simon Josefsson wrote:
>
> I tend to prefer ease of maintenance over optimizing code size for
> non-modern and/or non-GNU systems. The amount of system-replacing
> gnulib object code pulled in shouldn't be too large even on older GNU
I have seen regexp replaced on the then current
Sam Steingold writes:
> On 3/1/10, Simon Josefsson wrote:
>> Sam Steingold writes:
>> > as I said above, I do have a separate configure.in, gllib, glm4 in
>> > each module.
>>
>> I am confused. If they are separate, how could the gnulib generated
>> files conflict with each other?
>
> I use
Hi,
Ben Walton asked:
> I'm wondering whether its feasible to use gnulib in a project that
> doesn't use autoconf/automake?
I'm adding this clarification to the documentation:
2010-03-01 Bruno Haible
* doc/gnulib-tool.texi (Initial import): Clarify the requirements
regarding
On 3/1/10, Simon Josefsson wrote:
> Sam Steingold writes:
> > as I said above, I do have a separate configure.in, gllib, glm4 in
> > each module.
>
> I am confused. If they are separate, how could the gnulib generated
> files conflict with each other?
I use "gnulib-tool --avoid" to put the c
Sam Steingold writes:
> On 3/1/10, Simon Josefsson wrote:
>> >> >> > Since I use gnulib in several sub-modules, I need to avoid
>> conflicts
>> >> >> > between different gnulib imports.
>> >> >> > thus I need to make all those _GL_* constants module-specific.
>> >> >> > thus I need
On 3/1/10, Simon Josefsson wrote:
> >> >> > Since I use gnulib in several sub-modules, I need to avoid
> conflicts
> >> >> > between different gnulib imports.
> >> >> > thus I need to make all those _GL_* constants module-specific.
> >> >> > thus I need gnulib-tool to accept a --macro
Sam Steingold writes:
> On 2/27/10, Simon Josefsson wrote:
>> >> > Since I use gnulib in several sub-modules, I need to avoid conflicts
>> >> > between different gnulib imports.
>> >> > thus I need to make all those _GL_* constants module-specific.
>> >> > thus I need gnulib-tool to acce
On 2/27/10, Simon Josefsson wrote:
> >> > Since I use gnulib in several sub-modules, I need to avoid conflicts
> >> > between different gnulib imports.
> >> > thus I need to make all those _GL_* constants module-specific.
> >> > thus I need gnulib-tool to accept a --macro-prefix option and
Eric Blake wrote:
> Having just released m4-1.4.14, I noticed that gnu-web-doc-update is
> currently hardcoded to put the updated manual directly in $pkg/manual.
> But it seems like it might be nicer to support versioned manuals: both m4
> and autoconf copy the new manual into $pkg/manual/$pkg-$ver
Having just released m4-1.4.14, I noticed that gnu-web-doc-update is
currently hardcoded to put the updated manual directly in $pkg/manual.
But it seems like it might be nicer to support versioned manuals: both m4
and autoconf copy the new manual into $pkg/manual/$pkg-$ver, then update
$pkg/manual/
On 23 February 2010 00:34, Bruno Haible wrote:
> Hello Matěj,
>
> (how do you pronounce your name? like Matyesh?)
This one is quite difficult for English speaking people :-)
I have found this one on the web and it is quite accurate:
Approx English pronunciation for Matej: M as in "me (M.IY)" ; AA
20 matches
Mail list logo
