[CMake] getting the right set of Qt libraries

Clinton Stimpson clinton at elemtech.com
Thu Sep 17 17:08:44 EDT 2009


On Thursday 17 September 2009 02:56:02 pm Tyler Roscoe wrote:
> As noted in the other question I just posted, I'm collecting all my 3rd
> party dependencies into one place so my application is self-contained.
>
> I'm using FindQt4 to manage the Qt stuff. FindQt4 has some clever logic
> where each buildable unit that uses Qt can define the Qt submodules it
> needs:
>
> set (QT_USE_QTOPENGL 1)
> set (QT_USE_QTUITOOLS 1)
> etc.
>
> This system is nice because it means that a buildable only links against
> the Qt libs it needs, rather than linking against all 138314 individual
> Qt libraries every time.
>
> How do you guys insure that you have all the required libraries? I
> assume you're parsing ${QT_LIBRARIES} and copying each of those to your
> final destination.
>
> But let's say my main top-level executable only needs the Qt core lib,
> while several of the libraries that the executable depends on need QtXml
> or QtOpenGl or whatever?
>
> Do you just set all the QT_USE_* for all the submodules at the top level
> and make all of your buildables link against all these Qt submodules?
>
> Do you have some magic where each buildable sets QT_USE_* for the
> submodules it uses but then registers each of these submodules at the
> top-level so the top-level application can know which libraries it needs
> to copy to the destination directory?
>
> Something else?
>
> Hopefully this question makes sense. I'm again looking for The CMake Way
> to handle this scenario.

I mentioned BundleUtilities.cmake in another email.
It takes care of all this.  I suggest you try it out.

If you have any plugins with additional dependencies that your application 
might not have, there's an extra argument you can fill in.  A case of that 
would be copying Qt plugins and an image plugin depends on the QtSvg module 
where you app might not directly depend on it.

It uses ldd (Linux), otool (Mac), and dumpbin (Windows), to check 
dependencies.

Clint




More information about the CMake mailing list