On 02/05/2013 12:36 AM, Koehne Kai 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 (!).
I hope that no one would deploy a debug version fo the dll. Regardless, I would prefer that ICU is statically linked so I can clean up so of my .pro and .pri files a bit at least for Qt 5. > > 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....@qt-project.org >> [mailto:development-bounces+kai.koehne=digia....@qt-project.org] On >> Behalf Of Thiago Macieira >> Sent: Monday, January 14, 2013 4:52 PM >> To: development@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. > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
