Hi all,
On 2010-05-25, I wrote:
> Since that change, that introduced the m4/libunistring-base.m4 file,
> users of libunistring modules from gnulib *must* use the automake option
> 'subdir-objects'.
Ralf and I investigated this issue and found out [1][2] that there's simply
no reasonable way to ma
Hi all,
Since that change, that introduced the m4/libunistring-base.m4 file,
users of libunistring modules from gnulib *must* use the automake option
'subdir-objects'. The automake documentation makes it sound like the use
of the Automake option subdir-objects is merely a matter of style and
prefe
> > And AS_LITERAL_IF was not documented in Autoconf < 2.64.
>
> gnulib allows you to program (mostly) to Autoconf 2.64 interfaces.
If Eric adds AS_LITERAL_IF to m4/00gnulib.m4, I'll gladly use it in
gl_LIBUNISTRING_VERSION_CMP.
Bruno
On 05/19/2010 10:19 AM, Bruno Haible wrote:
2) What's the purpose of gl_LIBUNISTRING_VERSION_CMP_ORIG?
It serves as a backup, for the case that some day we need to pass computed
versions instead of literal versions.
So we can delete it, git will find it and the ChangeLog will say what
happen
Hi Paolo,
> 1) Is it so bad to drop the complicated code for 0.9-0.9.3 version
> detection, and just assume 0.9 if the hexversion is 9?
It may be possible three years from now. But currently, 0.9.3 is the newest
version available, and you'll notice that many modules carry 0.9.1 or 0.9.3
as minimu
> Here's what I'm committing, based on your original patches. This shows only
> the non-repetitive part of the commit. For the entire commit, please look
> in git.
Nice. Thanks for following up.
Two comments:
1) Is it so bad to drop the complicated code for 0.9-0.9.3 version
detection, and just
Hi Paolo,
Adding to the discussion from 2010-04-11: One point we did not think about
is versioning. New versions of libunistring are released with enhanced
functionality (more functions, or bug fixes). If the using package requires
that functionality, it imposes a constraint on the libunistring ve
On 04/11/2010 06:43 PM, Bruno Haible wrote:
> Then you don't even use libunistring-optional. libunistring-optional is
> what adds gl_LIBUNISTRING for you, basically.
Oh, I see. I was confused because I thought that modules/libunistring-optional
and m4/libunistring-optional.m4 belong together,
Hi Paolo,
> > In cases where only very little from libunistring is used, like the
> > 'unicodeio' module which only depends on 'unistr/u8-uctomb', it would be
> > overkill to link with -lunistring just for this.
>
> Then you don't even use libunistring-optional. libunistring-optional is
> what
On 04/11/2010 04:58 PM, Bruno Haible wrote:
Hi Paolo,
... requires nearly no additional change for the
user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it.
Not even that if the modules do that for him.
In cases where only very little from libunistring is used, like the
'
Hi Paolo,
> > ... requires nearly no additional change for the
> > user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it.
>
> Not even that if the modules do that for him.
In cases where only very little from libunistring is used, like the
'unicodeio' module which only depends
Thanks for doing that! It is simpler than the solution that I had imagined
for the use in gettext, and requires nearly no additional change for the
user: He adds 'gl_LIBUNISTRING' to his configure.ac and is done with it.
Not even that if the modules do that for him.
However, I disagree with
Hi Paolo,
> This series adds a libunistring-optional module. The purpose of the
> module is to allow using a system libunistring whenever present, while
> leaving the source code in the package too for the case when it is absent.
>
> The obvious step would be to make this the default. Unfortuna
On 04/10/2010 10:50 PM, Pádraig Brady wrote:
I had assumed that only the utils needing a built-in libunistring
would actually link it in, but thanks for confirming that.
I still was only considering a shared lib as there are now 100
coreutils and at least 10 would need libunistring.
Though in say
On 10/04/10 19:43, Paolo Bonzini wrote:
> On 04/10/2010 05:43 PM, Pádraig Brady wrote:
>> Thanks Paolo.
>> That's a nice feature to have.
>> I.E. statically link the lib when not present on the system.
>> It would be useful when one wanted to build a standalone sed
>> for example on older or non li
On 04/10/2010 05:43 PM, Pádraig Brady wrote:
Thanks Paolo.
That's a nice feature to have.
I.E. statically link the lib when not present on the system.
It would be useful when one wanted to build a standalone sed
for example on older or non linux systems, with the caveat
that the binary would be a
On 10/04/10 12:24, Paolo Bonzini wrote:
> This series adds a libunistring-optional module. The purpose of the
> module is to allow using a system libunistring whenever present, while
> leaving the source code in the package too for the case when it is absent.
Thanks Paolo.
That's a nice feature t
This series adds a libunistring-optional module. The purpose of the
module is to allow using a system libunistring whenever present, while
leaving the source code in the package too for the case when it is absent.
The obvious step would be to make this the default. Unfortunately,
this is hard be
18 matches
Mail list logo
