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: [email protected] [mailto:[email protected]] On Behalf Of Pau Garcia i Quiles Sent: 14. januar 2013 13:55 To: Konstantin Tokarev Cc: Thiago Macieira; [email protected] Subject: Re: [Development] ICU and Windows On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev <[email protected]<mailto:[email protected]>> 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)
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
