Deploying an Application on Mac OS X |
The additional code in tools/plugandpaint/mainwindow.cpp also enables us to view the plugins in the Finder, as shown to the left. We can also add plugins extending Qt, for example adding SQL drivers or image formats. We just need to follow the directory structure outlined in plugin documentation, and make sure they are included in the QCoreApplication::libraryPaths(). Let's quickly do this with the image formats, following the approach from above. Copy Qt's image format plugins into the bundle: cp -R /path/to/Qt/plugins/imageformats pluginandpaint.app/Contents/plugins Use install_name_tool to link the plugins to the frameworks in the bundle: install_name_tool -change /path/to/Qt/lib/QtGui.framework/Versions/4.0/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui plugandpaint.app/Contents/plugins/imageformats/libqjpeg.dylib install_name_tool -change /path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore plugandpaint.app/Contents/plugins/imageformats/libqjpeg.dylib Then we update the source code in tools/plugandpaint/main.cpp to look for the the new plugins. After constructing the QApplication, we add the following code: QDir dir(QApplication::applicationDirPath()); dir.cdUp(); dir.cd("plugins"); QApplication::setLibraryPaths(QStringList(dir.absolutePath())); First, we tell the application to only look for plugins in this directory. In our case, this is what we want since we only want to look for the plugins that we distribute with the bundle. If we were part of a bigger Qt installation we could have used QCoreApplication::addLibraryPath() instead. |
Warning: When deploying plugins, and thus make changes to the source code, the default identification names are reset when rebuilding the application, and you must repeat the process of making your application link to the Qt frameworks in the bundle using install_name_tool.
Now you should be able to move the application to another Mac OS X machine and run it without Qt installed. Alternatively, you can move your frameworks that live outside of the bundle to another directory and see if the application still runs.
If you store the frameworks in another location than in the bundle, the technique of linking your application is similar; you must make sure that the application and the frameworks agree where to be looking for the Qt libraries as well as the plugins.
When you are done linking your application to Qt, either statically or as frameworks, the application is ready to be distributed. Apple provides a fair bit of information about how to do this and instead of repeating it here, we recommend that you consult their software delivery documentation.
Although the process of deploying an application do have some pitfalls, once you know the various issues you can easily create packages that all your Mac OS X users will enjoy.
Your application may also depend on one or more Qt plugins, such as the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application, and note that each type of plugin should be located within a specific subdirectory (such as imageformats or sqldrivers) within your distribution directory, as described below.
The search path for Qt plugins (as well as a few other paths) is hard-coded into the QtCore library. By default, the first plugin search path will be hard-coded as /path/to/Qt/plugins. But using pre-determined paths has certain disadvantages. For example, they may not exist on the target machine. For that reason you need to examine various alternatives to make sure that the Qt plugins are found:
The How to Create Qt Plugins document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.
You can check which libraries your application is linking against by using the otool tool. To use otool, all you need to do is to run it like this:
otool -L MyApp.app/Contents/MacOS/MyApp
Unlike the deployment processes on X11 and Windows, compiler specific libraries rarely have to be redistributed along with your application. But since Qt can be configured, built, and installed in several ways on Mac OS X, there are also several ways to deploy applications. Typically your goals help determine how you are going to deploy the application. The last sections describe a couple of things to keep in mind when you are deploying your application.
Qt 4.2 has been designed to be built and deployed on Mac OS X 10.3 up until the current version as of this writing, Mac OS X 10.4 and all their minor releases. Qt acheives this by using "weak linking." This means that Qt tests if a function added in newer versions of Mac OS X is available on the computer it is running on before it uses it. This results in getting access to newer features when running on newer versions of OS X while still remaining compatible on older versions.
For more information about cross development issues on Mac OS X, see Apple's Developer Website.
Since the linker is set to be compatible with all OS X version, you have to change the MACOSX_DEPLOYMENT_TARGET environment variable to get weak linking to work for your application. You can add:
QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.3
to your .pro file and qmake will take care of this for you.
However, there is a bit of a wrinkle to keep in mind when your are deploying. Mac OS X 10.4 ("Tiger") ships GCC 4.0 as its default compiler. This is also the GCC compiler we use for building the binary Qt package. If you use GCC 4.0 to build your application, it will link against a dynamic libstdc++ that is only available on Mac OS X 10.4 and Mac OS X 10.3.9. The application will refuse to run on older versions of the operating system.
For more information about C++ runtime environment, see Apple's Developer Website
If you want to deploy to versions of Mac OS X earlier than 10.3.9, you must build with GCC 3.3 which is the default on Mac OS X 10.3. GCC 3.3 is also available on the Mac OS X 10.4 "Xcode Tools" CD and as a download for earlier versions of Mac OS X from Apple (connect.apple.com). You can use Apple's gcc_select(1) command line tool to switch the default complier on your system.
install_name_tool -change /System/Library/Frameworks/CoreVideo.framework/ Versions/A/CoreVideo /System/Library/Frameworks/QuartzCore.framework/ Versions/A/QuartzCore libphonon_qt7.dylib
This command must be invoked in the directory where libphonon_qt7.dylib is located, usually in yourapp.app/Contents/plugins/phonon_backend/.
./CONFIGURE - SDK MacOSX10.4u.sdk
The Qt for Mac OS X libraries, tools, and examples can be built "universal" (i.e. they run natively on both Intel and PowerPC machines). This is accomplished by passing -universal on the configure line of the source package, and requires that you use GCC 4.0.x. On PowerPC hardware you will need to pass the universal SDK as a command line argument to the Qt configure command. For example:
./configure (other arguments) -universal -sdk /Developer/SDKs/MacOSX10.4u.sdk
From 4.1.1 the Qt binary package is already universal.
If you want to create a binary that runs on older versions of PowerPC and x86, it is possible to build Qt for the PowerPC using GCC 3.3, and for x86 one using GCC 4.0, and use Apple's lipo(1) tool to stitch them together. This is beyond the scope of this document and is not something we have tried, but Apple documents it on their developer website.
Once you have a universal Qt, qmake will generate makefiles that will build for its host architecture by default. If you want to build for a specific architecture, you can control this with the CONFIG line in your .pro file. Use CONFIG+=ppc for PowerPC, and CONFIG+=x86 for x86. If you desire both, simply add both to the CONFIG line. PowerPC users also need an SDK. For example:
QMAKE_MAC_SDK=/Developer/SDKs/MacOSX10.4u.sdk CONFIG+=x86 ppc
Besides lipo, you can also check your binaries with the file(1) command line tool or the Finder.
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. | Qt 4.4 | |
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD. | ||
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP ! |
Copyright © 2000-2012 - www.developpez.com