Mac OS Lion : compilation script forgets to move dylib files in .app package.

[pbernery]

The produced .app folder is not usable as is because the .dylib files built are not copied or linked in the pyrogenesis folder. When trying to execute pyrogenesis, the following error occurs:

dyld: Library not loaded: @executable_path/libmozjs185-ps-release.1.0.dylib
  Referenced from: <ad>/binaries/system/pyrogenesis.app/Contents/MacOS/./pyrogenesis
  Reason: image not found

I managed to make it work by making a symbolic link of all dylib files in the pyrogenesis folder:

cd <ad>/binaries/system/pyrogenesis.app/Contents/MacOS
ln -s ../../../*.dylib .

The executable launches (on the command line only by typing ./pyrogenesis, not by opening the .app folder) and works pretty well. I just miss the sound but this should be another problem.

[pbernery]

I made a script to copy all dylib files and also change the install names of linked libraries. The .app directory is then openable from the Finder. The app is not running fullscreen though (and the windowed mode does not show the window bar, the window is thus not movable). The script must currently be executed from the binaries/system directory.

[historic_bruno]

We definitely shouldn't do the symbolic link thing, because that breaks the concept of an app bundle as a self-contained package. We'll also want to make sure we follow the guidelines for ​bundle structure, which indicates the libraries should be placed in MyApp.app/Contents/Frameworks/ rather than next to the binary, so they'll override existing system libraries. Then we could modify the engine to support loading libraries from there, and avoid the need for install_name fiddling.

[pbernery]

Replying to historic_bruno:

We definitely shouldn't do the symbolic link thing, because that breaks the concept of an app bundle as a self-contained package.

I agree about the symlink thing. My script does copy files instead of doing a symlink.

We'll also want to make sure we follow the guidelines for ​bundle structure, which indicates the libraries should be placed in MyApp.app/Contents/Frameworks/ rather than next to the binary, so they'll override existing system libraries. Then we could modify the engine to support loading libraries from there, and avoid the need for install_name fiddling.

Ok, I could have a look at this. I'm a bit lost with all files in the project. Could you point me where I should put the script that will do that or which script I should update.

Also, I think all non-system dependencies should be in the package. What do you think about browsing the pyrogenesis executable dependencies (with otool -L) and copy them in the bundle?

[historic_bruno]

Replying to pbernery:

Ok, I could have a look at this. I'm a bit lost with all files in the project. Could you point me where I should put the script that will do that or which script I should update.

Also, I think all non-system dependencies should be in the package. What do you think about browsing the pyrogenesis executable dependencies (with otool -L) and copy them in the bundle?

Yes, all the game data would have to be copied into the bundle as well, I assume somewhere inside Myapp.app/Contents/Resources/. As far as how and when to do this, it's a bit tricky because OS X developers will want to keep the SVN structure around to keep up-to-date, but most users will only want the bundle. So I would lean toward having a new script to copy all the libraries and data, which can be run optionally to make a bundle "release".

I can't believe everyone has to do this setting up the app bundle manually, Xcode should be able to do most of it, assuming we generate a proper xcode project, though I don't have the experience with Xcode to know exactly what's missing and what the steps are.

[historic_bruno]

No longer an issue as we don't build a bundle by default since r10946. There will be a separate process for creating an app bundle (currently a work in progress).