[cmake-developers] DeployQt5/generalizing DeployQt4 for Qt5

[Marcus D. Hanwell]

On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Marcus D. Hanwell wrote:
>
>> Hi,
>>
>> Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
>> We use it in our packaging process, and it is one of the last things I
>> need to switch to Qt 5. If not, I was going to take a look at this,
>> and see what I can put together.
>
> I've never used DeployQt4 or BundleUtilities, and I don't know much about
> Mac (which BundleUtilities seems to strongly relate to somehow), so I don't
> know what is needed from a DeployQt5, which is why I haven't written such a
> thing yet. It seems like something that should be versioned with and shipped
> with Qt 5.

It was contributed by Mike McQuaid (from KDAB too I think). How are
you currently packaging Qt application binaries on Windows, Linux and
Mac?
>
> The intersection of people who know a lot/enough about CMake, packages, and
> DeployQt4, and Qt 5 is a small set. Please help me with these questions:

Sure, David Cole actually wrote a lot of the packaging code that uses
DeployQt4, but I will do my best (he will hopefully correct me if I
miss anything).
>
> * What is so special about Qt deployment that it needs special handling in
> CMake? Why is there no (to pick some random examples) DeployLibLZMA,
> DeployMPEG, DeployVTK etc? Is it really mostly just the path adjustment
> stuff and the qt.conf?

Path adjustment, qt.conf, locations of binaries for release/debug on
Windows, Qt is different enough that packaging it needs some simple
helpers. Using it with bundle utilities helps to track down all of the
necessary dependencies that should be put in a binary package, and
avoids attempting to copy system files by going too far.
>
> * How is it used in real-life? How does it intersect to cpack related code?

The MoleQueue application is perhaps one of the simpler ones where we
use it with CPack to create Windows and Mac installers automatically.
>
> * It was written in a different era of CMake design. How do things like
> guaranteed use of IMPORTED targets (as Qt 5 ensures), listing of the
> libraries in INTERFACE_LINK_LIBRARIES, or other modern features of CMake
> affect the design of DeployQt5?

I think it would still need the same kind of logic to bring in libs
that Qt libraries link to, Qt plugins, etc. Knowing which libraries
are linked to and their location was always the simpler piece, putting
the qt.conf file in the correct location, bringing along the correct
Qt plugins, etc, fixing up the paths of the binaries to only reference
the bundled Qt are all taken care of for us with this helper.
>
> * It seems to have macros related to plugins. When using a statically built
> Qt, plugins are also relevant in the buildsystem because I need to compile
> them into my application. Should there be one generic interface in CMake for
> both this kind of thing and what DeployQt4 is doing?

Perhaps, but I am most concerned at this point with the simplest way
of porting the remaining part of the build system. I would prefer
something like DeployQt4 for simplicity, and not requiring me to bump
my Qt dependency to 5.3 for packaging, so in the short term at least I
would like to offer similar functionality for Qt 5 in a CMake helper.
>
> * How should the parameters of the functions be changed? They seem to not
> use MacroParseArguments.

I have no strong opinions, I am happy to show you how we currently use
it. The new Qt 5 CMake support seems really strong, but I was left
wondering what I should do for packaging. I would like something that
would work with Qt 5.0+, I am not overly tied to DeployQt4 if there is
a better way to do this, but hope to get something that is similarly
robust once it is up and running in our projects.

Thanks,

Marcus