[Interest] Replacing icudtXX.dll without rebuilding Qt?

Elvis Stansvik elvstone at gmail.com
Sun Jan 17 16:25:32 CET 2016


2016-01-17 15:46 GMT+01:00 John Layt <jlayt at kde.org>:
>
>
> On 17 January 2016 at 14:30, Elvis Stansvik <elvstone at gmail.com> wrote:
>>
>> 2016-01-17 14:48 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>> > Hi all,
>> >
>> > In an effort to cut down on the size of the standalone ZIP
>> > distribution of my small command line tool [1] which only uses QtCore,
>> > and which to my knowledge does not depend on any localization
>> > features, I'd like to try replacing the icudtXX.dll that I currently
>> > take from the Qt bin directory with a custom one built using the ICU
>> > Data Library Customizer [2].
>>
>> I've slightly misunderstood how the ICU Data Library Customizer works.
>> I thought it would generate a icudtXX.dll, but it generates a .dat
>> file to be used in the compilation of ICU.
>>
>> So now that I know that I have to re-build ICU with this .dat file, my
>> question are:
>>
>> 1. Is it safe to replace the three icuXXXX.dll DLL files without also
>> re-building Qt, provided that I use the exact same ICU version,
>> compiled with the exact same compilation flags, but with a different
>> .dat file?
>>
>> 2. If so, which parts of the .dat file can I safely exclude with the
>> ICU Data Library Customizer? I don't think I need any of the features
>> which Qt uses ICU for, but are there some parts that must be included
>> for Qt to function at all?
>>
>> 3. Where can I find out how the ICU bundled with official Qt builds was
>> built?
>
>
> Advice for compiling ICU can be found at
> https://wiki.qt.io/Compiling-ICU-with-MSVC, you don't need to worry about
> compatibility so much as ICU offers no binary compatibility guarantees so Qt
> only uses the C interface.

Right, I saw that page. It describes how to build ICU with MSVC, and then says:

    "This will generate a release shared build that you can use in
both a debug and release build of Qt."

It's this sentence which made me wonder if I'll also need to re-build
Qt, or if I can just use the new DLLs as a drop-in replacement?

>
> Frankly though, ICU is a pain to build and if you're rebuilding anything I'd
> suggest you just rebuild Qt instead with the no ICU flag set. The only thing
> you loose on Windows are proper collation support for Win XP, proper
> toUpper/toLower support in tricky languages, and various Unicode look-up
> tables. If you're not worried about those then this is a better path for
> you.

I see, yes, that would give me the smallest possible deployment, and
also be the "safest" way (no worries about replacing DLLs). However, I
found it so convenient that the Appveyor CI has recent versions of the
official Qt builds pre-installed. Building a custom Qt on Appveyor is
out of the question (the build would time out), and I don't have a
Windows machine myself. So to use a custom Qt, I would have to dig out
a Windows machine somewhere each time I want to update Qt.

But I realize now that an ICU build on Appveyor is perhaps out of the
question for the same reason. It's a pretty large library after all.
Do you know how long a build roughly takes on a modern machine?

I'll have to think a bit if all this is actually worth the trouble. If
it's too much hassle, I'll just abandon the idea and live with a 11 MB
ZIP.

Thanks for the advice.

Elvis

>
> John.
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



More information about the Interest mailing list