Deploying a mac package
-
Hello,
i work normally with a windows platform, and wrote now a multiplatfor application. I use Installbuilder to package my application and right now i put every library into th package (about 50 MBytes) because i couldnt find a information how to tell the app where it has to search for the libs.
is there a tutorial for this somewhere or can somebody give me a hint for what i have to search to find some information on this subjectwith regards
Georg -
The following piece of "documentation":http://doc.qt.nokia.com/4.7/deployment-mac.html#macdeploy contains information regarding deployment on Mac. Does that help?
-
I've made a script that automatically relink Qt lib, your application and plugins if you provide all the files (application, plugins and framework) in a mac application bundle. You just have to run it once before packaging your installer, or after your installer has finished deploying the files.
It has to be in the root of the bundle (Contents/) along with install_name_tool utility. -
On the Mac, you usually do not have any installer. Put the libraries, plugins, resources and everything else into the application bundle. Then create a ZIP or - better - a disk image (DMG) from which your target user just drags and drops the application. That's what Mac users expect for simple applications.
-
Hello,
this with the app package i know. Ma problem here is, i have to bundle then about 50 MBytes libraries and the app itself is only 10, this takes arougn 15minutes for the download.
On windows i can get normally the installpath of a needed application and take this as the lib path so i do not need to put these libs into the package - how can i do this on a macGeorg
-
Mac binaries are always huge. Depending on the used system libs (carbon/cocoa) and CPU platform they can contain binary code for up to four architectures (i386, i386_64, ppc, ppc64).
Your statement about windows is nonsense. Qt is not a system library, you cannot rely on it being installed already. So your installer package has to provide them as well and is as big as your app plus Qt libs. Compared to a Mac bundle, it's usually smaller in size though, as there is only one architecture in it.
-
i dont speak from qt libs, i mean other libs from packages the user already has installed or installs seperately, because these libs will not change when i provide an update, it makes no snese for the user to redownload them everytime again
Georg
-
I don't understand the question. If it is a prerequisite of your application, then those parts must be installed before your application. Then you know the paths, as it should be in standard locations. Otherwise you're lost anyways.
If you cannot guarantee that the components are preinstalled in any way, you will have to provide them yourself anyways.
If you need some update mechanism, look for auto updaters for the Mac (e.g. "Sparkle":http://sparkle.andymatuschak.org/) which provide means for updating only the changed components.
Put your stuff in a complete bundle and you're done. Everything else breaks Mac user experience. You can have installers (pkg), even ones with multiple subpackages (mpkg) in the Mac. But that's only for libraries or stuff that has to go into system directories or the like. Having to install a myriad of packages will make the Mac crowd angry.
Remember that Apple slogan from back in the 90ies? "Think different":http://en.wikipedia.org/wiki/Think_Different - adhere to it :-) You cannot adapt Windows habit one to one...
-
I have found the macdeployqt works great. I usually deploy with the drag-n-drop method but I have some legacy code that I'd just as soon not modify much that relies on some support files in the users home folder. I fairly easily got packagemaker to put the files in the home folder using post-scripts. But every time I run my pkg, it skips all of my QT developed *.app files. I can put other .app files in and they appear in the /Applications folder just fine, but my QT created (after running macdeployqt) never get copied, even though the installer tells me it finished successfully. Anyone had this problem?
-
elyness,
I think that that the consideration should be out of the Qt packaging question.
If the previously installed stuff is a set of components i.e. libraries or commands etc that - to be clear - will be managed / called by the application the problem is how these packages should be installed. To give and example the Inkscape porting on Mac will work as do Gimp and other programs with the "X" component for Mac. This means that you before install the "X" component that is packaged in a way so that the application can start from the aplication menu but also called automatically like any other Mac OS-X command. After installing and running Inkscape or Gimp you see that if it is not running yet "X" component will start before.
The legacy stuff that you should have external to your package need to be installed somewhere in the Mac OS so that it can be managed / launched by other applications (i.e. the programs under /bin, or /usr/bin or /usr/sbin and this means as I understand, that:
- Your application package should be app as you have already done
- The legacy stuff should be packaged for install separately (i.e. deployed only in the first installation or as a "needed package"
- Your users should install / update their application in the conditions that the legacy stuff is already present in the computer.
What the application should do is to check the presence of these files or libraries when start and - if not - notify it to the user.
Can be a method ?
