[cmake-developers] Qt Bundle Utilities/Packaging

[Mike McQuaid]

On 20 April 2011 15:24, Clinton Stimpson <clinton at elemtech.com> wrote:
>> 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?

Indeed. However, the Mac version is safe and doesn't require any
compile-time adjustments.

I don't mind if it's configurable, I just want the defaults to be
sensible as that's what most users will use.

>> 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.

In which case you can pass it in as an argument. I'm not opposed to
having it added automatically though. At install-time do you think
this should just use the version passed in at CMake time so pass that
variable into the install_code block? Is it safe to assume it's always
going to be defined?

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

By using the qtplugins argument, no? Perhaps I've misunderstood you.

> 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.

Cool.

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

We might remove that but I've had to use it whenever using a version
of Qt that isn't writable by the user doing the fixup (e.g. installed
by Homebrew/Macports/Linux package manager)

> 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.

I guess I just thought the solution was simple enough that they
weren't needed and I wanted something standalone for evaluation at the
moment. If you can integrate the two sensibly and you think it saves
code please feel free.

Thanks for your feedback!

-- 
Mike McQuaid
http://mikemcquaid.com