Re: [swift-corelibs-dev] Measurement Formatters & ICU

[Philippe Hausler via swift-corelibs-dev]

Just because it was super-easy for me to fix:

https://github.com/apple/swift-corelibs-foundation/pull/587

That should allow C++ to be built if desired into CoreFoundation. However round 
tripping that into the Darwin version of CoreFoundation may be a bit cagey.

> On Aug 23, 2016, at 4:53 PM, Henry Betts  wrote:
> 
> 
>> On 23 Aug 2016, at 16:58, Philippe Hausler  wrote:
>> 
>> Is there a specific version of ICU that we need to pick that functionality 
>> up? As it stands we don’t have a upper version limit on ICU but if we had a 
>> portion of the ICU source in CF it would probably mean that we would get 
>> symbolic conflicts when linking against versions that already had that.
> 
> 
> Looks like the C++ MeasureFormat (and friends) have existed since ICU 3.0, 
> although they have not yet got around to implementing a C interface. I don’t 
> think symbolic conflicts would occur, since, if ICU did eventually introduce 
> the C interface, I assume that it would use just a “u” prefix rather than 
> “ua”. Not sure if that’s what you meant.
> 
> Alternatively, I suppose we could just bypass uameasureformat, and interact 
> with the c++ api directly in CF, since it looks like it’s going to have to be 
> setup to compile c++ anyway.
> 
> Henry

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Measurement Formatters & ICU

[Philippe Hausler via swift-corelibs-dev]

+Daphne since she was the one who implemented the Darwin version of the unit 
and measurements and I think she has some ideas on how we could perhaps build a 
uniform version for Linux hosts.

Per the C++; the script for that phase probably needs a bit of love since we 
haven’t had a need for C++ to be built in CF. 

Is there a specific version of ICU that we need to pick that functionality up? 
As it stands we don’t have a upper version limit on ICU but if we had a portion 
of the ICU source in CF it would probably mean that we would get symbolic 
conflicts when linking against versions that already had that.

> On Aug 22, 2016, at 1:36 PM, Will Stanton via swift-corelibs-dev 
>  wrote:
> 
> I recall the time formatter being deprecated in favor of measfmt, so you 
> might be right that uatimeunitformat isn't needed. I think some functions in 
> uatimeunitformat.cpp made combining units easier when calling from (then 
> NS)DateComponentsFormatter, but perhaps that can be put functionality in a 
> (Swift-)CFDateComponentsFormatter wrapper. (Not sure if Apple will come out 
> with its own CFDateComponentsFormatter).
> 
> 
> I think this was what I had to change to get C++ working:
> https://github.com/apple/swift-corelibs-foundation/blob/master/lib/phases.py
> The includes for CompileCxx should be more like CompileC.
> 
> Regards,
> Will Stanton
> 
> Sent from my iPhone
> 
>> On Aug 22, 2016, at 15:58, Henry Betts via swift-corelibs-dev 
>>  wrote:
>> 
>> Yes - I was planning on including uameasureformat.cpp for the linux build, 
>> although I was also unsure whether the build script was setup to compile c++.
>> Noticed a bug in uameasureformat.cpp by the way; DURATION_DAY and 
>> DURATION_WEEK are the wrong way around!
>> 
>> I’m a bit confused by uatimeunitformat. I’m probably missing something 
>> obvious, but what can it do that uameasureformat can’t do?
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev