[Development] ICU and Windows

[Shaw Andy]

To get things back on track, I think we have a case for either way saying that we could ignore it as since as long as it's done the correct way then it should be fine.  But there is also a case for doing the right thing as far as what is recommended by Microsoft in this case especially since we are in the position to actually get it right.  So far I haven't seen a reason why we shouldn't ensure we use the appropriate runtime libraries to ensure they do not get mixed on Windows.

Therefore I would like to propose that for 5.0.1 we simply modify the pro file so that it expects a d after the library name for the debug version and the release one stays as it is.  What we could do to make it more robust is connect it into configure so it checks if it exists and if it does not fall back onto the release version (and give a warning) so it will continue to build as before.

Then in 5.1.0 we put ICU into the 3rdparty directory and then we have more control over it and build it ourselves as it seems that this would give us more benefits long term from what John Layt said in a previous mail.

How does this sound, is there anything that would mean that this is not a good thing to do?

Andy

From: development-bounces+andy.shaw=digia.com at qt-project.org [mailto:development-bounces+andy.shaw=digia.com at qt-project.org] On Behalf Of Pau Garcia i Quiles
Sent: 14. januar 2013 13:55
To: Konstantin Tokarev
Cc: Thiago Macieira; development at qt-project.org
Subject: Re: [Development] ICU and Windows


On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev <annulen at yandex.ru<mailto:annulen at yandex.ru>> wrote:

>> On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote:
>>> Which is not always that easy... if a library function returns, say, an
>>> simple std::string *by value*, then who will destroy the allocated memory?
>>> It's really too easy to break something, somwhere, causing a random crash
>>> almost impossible to reproduce reliably.
>>
>> The ICU C API does not use std::string: it was meant to be used from C code.
>> It's quite easy to avoid std::string in that case.
>
> But as John said a few mails ago, it seems the C is not enough to implement all the required features.
ICU provides C++ API but it does not use std::string. It operates on char * or UnicodeString objects.


std::string is just one case, the C++ API does allocate other objects and I'm sure that was what Yves (and me) wanted to highlight

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130114/ec0ed9c2/attachment.html>