On 20 April 2011 15:24, Clinton Stimpson <clin...@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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers