On 3/2/10, Simon Josefsson wrote:
>
> > it would be not necessary if the --*-common arguments are introduced
> > because then the macro prefix can be generated automatically.
>
>
> But I don't see how it would work because of module interdependency's.
> I think there are two main cases:
>
> 1)
Sam Steingold writes:
> On 3/2/10, Simon Josefsson wrote:
>> Sam Steingold writes:
>>
>> > 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
>> >> dif
On 3/2/10, Simon Josefsson wrote:
> Sam Steingold writes:
>
> > 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 organ
Sam Steingold writes:
> 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-t
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
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
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
Sam Steingold writes:
> On 2/26/10, Simon Josefsson wrote:
>> Sam Steingold writes:
>>
>> > 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
On 2/26/10, Simon Josefsson wrote:
> Sam Steingold writes:
>
> > 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
Sam Steingold writes:
> 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 this patch:
I believe the recommended
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 this patch:
iff --git a/gnulib-tool b/gnulib-tool
index ea451ec..6ed
19 matches
Mail list logo
