[cmake-developers] Qt Bundle Utilities/Packaging

Clinton Stimpson clinton at elemtech.com
Wed Apr 20 10:24:16 EDT 2011


On Wednesday, April 20, 2011 05:18:41 am Mike McQuaid wrote:
> On 7 April 2011 18:17, Clinton Stimpson <clinton at elemtech.com> wrote:
> > I think you should *always* write out a qt.conf file.
> > The Qt libraries have hardcoded paths (used if there is no qt.conf file)
> > and if the target machine has a Qt installation at the same location as
> > the build machine, it could get the target machines plugins instead.
> >  These plugins are tied to a specific version and configuration of Qt,
> > so they cannot be mixed.  On Mac, the problem of a missing qt.conf is
> > immediate on the build machine.
> 
> In my experience this isn't needed on Mac and can/should instead be
> set by calling QApplication::setLibraryPaths or embedding qt.conf as a
> resource on Windows or Linux. I think on both of those platforms it's
> fairly unpleasant to just have a plain-text qt.conf file sitting in
> your binary directory.

But not everyone does it that way.
And from these docs:
http://doc.qt.nokia.com/latest/qt-conf.html
it seems possible to embed a qt.conf on Mac as well.

I don't think it is correct to switch the behavior with an if(APPLE).
How about letting the user pass in a flag?

> 
> > I think we should add QT_LIBRARY_DIR to fixup_bundle()'s dirs all the
> > time.
> 
> This isn't always necessary and is hard to get at install time. My
> solution still allows this to be done optionally if it can't be found.

Sure, it may not always be necessary, but we don't know the Qt setups on the 
users machines, and the script should be robust.

For example, we have a windows machine that does multiple nightly builds from 
scripts (both 32 and 64 bit).  The developer on that machine can use a 
different Qt version.  Also, it has both 32 and 64 bit Qt dlls in the path, and 
one of them is first in the path.  If QT_LIBRARY_DIR/QT_BINARY_DIR isn't used 
with BundleUtilities, it doesn't get done right.

> 
> > Have you thought about letting the user supply a list of their own
> > plugins and having the function add the default Qt plugins to that list
> > (or a set of plugins based on the QT_USE_* variables)?
> 
> I'd rather install only the minimal amount of plugins rather than
> automatically install them all. Most applications using e.g. QtSQL
> will only use a single plugin, not multiple.

Yeah, for QtSQL, that is usually the case.
How does the user call install_qt4_app() with a list of plugins?

BTW, I was asking about users's *own* plugins that they built, which could 
have their own non-Qt dependencies.  But it looks like install_qt4_app() can 
handle that.

> 
> > Also, one frequent complaint with using these functions is the user
> > having to do
> > install(CODE ".... ") and worry about escaping quotes and dollar signs.
> > Do you think this would be a good time to address that?
> 
> Have added a "install_qt4_app" which should deal with this.

Thanks.

> 
> Patch attached for something actually tested and working for two
> internal projects.


And what's the 
SET( BU_CHMOD_BUNDLE_ITEMS TRUE )
for?

Also, you said something before about using the install plugins macros, but 
this patch doesn't use them.  I'm curious why that didn't work out.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com



More information about the cmake-developers mailing list