0

I have a Qt app that uses Assistant to display help.

On Mac, I am packaging he Assistant inside the bundle. The only way I can include all its libraries is by placing the Assistant executable inside the same MacOS folder as the app executable, and properly link all the library dependencies.

Is there a way to place information about both executables in the Info.plist ?

Thalia
  • 13,637
  • 22
  • 96
  • 190

3 Answers3

1

No, you can't put info about multiple executables inside the same Info.plist. (Well, you an always puts custom keys into the Info.plist and store whatever property list data you like there, but the system won't pay any attention to those keys.)

Why not bundle the Assistant into its own bundle and put that bundle inside the main app's bundle? The Assistant bundle would have its own Info.plist file. Also, if you create a question about whatever linking or dynamic loading problems made you think you had to put it all into the main bundle, you might find there's a better solution.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
  • I have asked a lot of questions about bundling the Assistant together with the app... The reason I placed it together with the app instead of its own bundle is, because I would have to include the Qt frameworks for both the app and Assistant otherwise... I did not find a way to make it work to link Assistant to the frameworks located inside the app bundle (see my question http://stackoverflow.com/questions/26978764/how-do-i-deploy-assistant-with-my-app-on-mac-without-deploying-multiple-copies-o_ – Thalia Nov 19 '14 at 22:36
1

placing the Assistant executable inside the same MacOS folder

I recommend not to do this. The Assistant is a resource to the main application and so it should reside in the resources folder. If you want to launch the Assistant app from the main app, you can then locate it by name.

You can only define one application in the Info.plist. If you were to add more, there would be a conflict in keys.

For example, CFBundleIdentifier is a unique URI that names the bundle (e.g. com.apple.calculator). The OS uses the URI to register the application with the OS when an application is, for example, copied to the /Applications folder. The OS expects the key to be a child of the root dictionary and its value must be unique. If there were multiple keys named CFBundleIdentifier, it would not know which is valid.

Community
  • 1
  • 1
TheDarkKnight
  • 27,181
  • 6
  • 55
  • 85
0

Although you can throw almost any junk into a Mac application bundle, much good will not come to you.

If I understand right, you have both a Mac Application (bundled normally) and a side-application you call the "Assistant" you want embedded in the same application bundle.

You also mention libraries (.dylib's I guess) that must reside in the same directory as the assistant.

Now - if these libraries are only used by the Assistant side-application, I would recommend that you bundle the assistant as a Code-bundle (Apple provides lots of information about these, and you have easy to use templates from Xcode). You can then use Xcode to copy it into the right place within the main application's bundle (I'd choose "Plugins") and use NSBundle APIs to launch it.

However, if those .dylibs are shared between the main app and the assistant - then I'd say go ahead, stick your assistant, .dylibs and main app's binary files in the same "MacOS-X" directory, and use posix APIs, or shell command to launch the assistant. Of course it will share (if possible) every resource of the main application, because they are located at the same place. However, the main app's bundle can only have ONE CFBundleExecutable entry, and that should point to your main application's binary.

Motti Shneor
  • 2,095
  • 1
  • 18
  • 24
  • Thank you for response - my app was built in Qt, and used Qt's Assistant as a Help tool - so many of the Qt framework libraries (dylib) were shared between the two. I ended up with a compromise... – Thalia Feb 03 '16 at 14:47