[Development] ICU and Windows

[Knoll Lars]

On Feb 4, 2013, at 3:36 PM, Koehne Kai <Kai.Koehne at digia.com>
 wrote:

> Hi,
> 
> Importing ICU into qtbase is fine with me. Anyhow, I don't particular like hard dependency to ICU from Qt5Core, since it forces everyone deploying a Windows helloworld to also ship icudt49.dll with 17,5 MB (!).

No, please not. I don't want to add such a huge module to 3rdparty. At most, I could live with a git submodule.

Cheers,
Lars

> 
> I know that you can still configure with -no-icu. So how about making the usage of ICU a runtime decision? Has anybody looked into this already? And are we up to maintain the old, internal backend also in future versions?
> 
> Regards
> 
> Kai
> 
>> -----Original Message-----
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
>> Behalf Of Thiago Macieira
>> Sent: Monday, January 14, 2013 4:52 PM
>> To: development at qt-project.org
>> Subject: Re: [Development] ICU and Windows
>> 
>> On segunda-feira, 14 de janeiro de 2013 13.02.46, Shaw Andy wrote:
>>> 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?
>> 
>> I think it's too late for 5.0.1. We could do it for 5.0.2, but I'll insist that we
>> don't change anything for 5.0.x, unless it is proven that we are doing things
>> wrong.
>> 
>> Let's do the import into 3rdparty for 5.1.0 then, if that's the solution we agree
>> upon. And Pau is right: if we need to access the C++ API to get enough
>> information for some of our APIs, we'll need to build ourselves for MinGW
>> anyway.
> 
>