On Wed, Dec 16, 2015 at 01:40:47PM +0100, Antoine Jacoutot wrote:
> On Wed, Dec 16, 2015 at 01:32:21PM +0100, Jérémie Courrèges-Anglas wrote:
> > Tinker writes:
> >
> > > On 2015-12-16 05:04, j...@wxcvbn.org wrote:
> > >> Tinker writes:
> > >>
> >
Wait, in the interim, the brave user who wants ICU support system-wide
now, and who has ICU already installed in the system, can just switch
the "--without-icu" part to "--with-icu" in
/usr/ports/devel/boost/Makefile , and do "make; make install" right?
That will not break binary
On Thu, Dec 17, 2015 at 06:27:07AM +0800, Tinker wrote:
> Wait, in the interim, the brave user who wants ICU support system-wide now,
> and who has ICU already installed in the system, can just switch the
> "--without-icu" part to "--with-icu" in /usr/ports/devel/boost/Makefile ,
> and do "make;
On Wed, Dec 16, 2015 at 1:32 PM, Jérémie Courrèges-Anglas
wrote:
> We have one report here:
>
> http://marc.info/?l=openbsd-ports=144171504417490=2
>
> jirib didn't confirm that ICU was the only thing needed to make his
> aegisub port work, and to my knowledge no existing port
On Wed, Dec 16, 2015 at 01:32:21PM +0100, Jérémie Courrèges-Anglas wrote:
> Tinker writes:
>
> > On 2015-12-16 05:04, j...@wxcvbn.org wrote:
> >> Tinker writes:
> >>
> >>> What would the decision be based on?
> >>
> >> I think that those points
On 2015-12-16 18:23, Landry Breuil wrote:
On Wed, Dec 16, 2015 at 06:10:17PM +0800, Tinker wrote:
Aha thank you very much for pointing these things out - great to know
there
was a discussion about it.
Aha so maybe for OpenBSD 6.0 we'll have an ICU flavor at least.
Flavors in libraries are
On 2015-12-16 05:04, j...@wxcvbn.org wrote:
Tinker writes:
What would the decision be based on?
I think that those points should be enough.
- good reasons to use ICU in boost, not just "I need the ICU parts of
Boost.". What would be the benefit for the ports tree?
Tinker writes:
> On 2015-12-16 05:04, j...@wxcvbn.org wrote:
>> Tinker writes:
>>
>>> What would the decision be based on?
>>
>> I think that those points should be enough.
>> - good reasons to use ICU in boost, not just "I need the ICU parts of
>>
Aha thank you very much for pointing these things out - great to know
there was a discussion about it.
Aha so maybe for OpenBSD 6.0 we'll have an ICU flavor at least.
I understand that the ICU support in Boost interfered with some other
package so it wasn't completely untrivial to include and
On Wed, Dec 16, 2015 at 06:10:17PM +0800, Tinker wrote:
> Aha thank you very much for pointing these things out - great to know there
> was a discussion about it.
>
> Aha so maybe for OpenBSD 6.0 we'll have an ICU flavor at least.
Flavors in libraries are really a pain to handle, so we try to
What would the decision be based on?
Everyone just rolling thumbs or is there any real tradeoff?
I guess anyhow that it's fair to say that OpenBSD machines do process
Unicode and not just Ascii and that the Unicode usecase only will grow
with time.
On 2015-12-16 01:04, Kirill Bychkov
On Tue, December 15, 2015 19:48, Tinker wrote:
> Hi,
>
> I need the ICU parts of Boost. And, I really guess internationalized
> stuff is becoming more and more popular.
>
> Currently:
>
> /usr/ports/devel/boost$ grep -r icu *
> Makefile: --without-icu \
>
> Would you feel
Stuart Henderson writes:
> On 2015/12/15 22:04, Jérémie Courrèges-Anglas wrote:
>> Tinker writes:
>>
>> > What would the decision be based on?
>>
>> I think that those points should be enough.
>> - good reasons to use ICU in boost, not just "I need
Tinker writes:
> What would the decision be based on?
I think that those points should be enough.
- good reasons to use ICU in boost, not just "I need the ICU parts of
Boost.". What would be the benefit for the ports tree?
- someone has to do the work, and that
On 2015/12/15 22:04, Jérémie Courrèges-Anglas wrote:
> Tinker writes:
>
> > What would the decision be based on?
>
> I think that those points should be enough.
> - good reasons to use ICU in boost, not just "I need the ICU parts of
> Boost.". What would be the benefit
15 matches
Mail list logo