[CMake] SDL troubles on Mac OS X

[David Cole]

On Wed, Dec 16, 2009 at 1:48 AM, Michael Wild <themiwi at gmail.com> wrote:

>
> On 15. Dec, 2009, at 23:46 , Glenn Hughes wrote:
>
> >> I think the SDL developers are just being a bit "too" slick. They are
> setting up SDL for Xcode development where typically you would link to the
> SDL and then have a "Copy Files Phase" where you copy the framework into the
> Application Bundle that resides in the build directory.
> >
> > Its a cultural difference also. Mac developers think of creating the
> > complete application as part of the build process. A Mac app generally
> > contains everything it needs so you can just drag it to another
> > machine and run it. I would never want a half-baked app that is wired
> > into my machine. Copying the libraries into the app isn't part of
> > "installation", its part of "building"... Copying the app somewhere
> > else is "installation" i.e. a no-op as far as my build process is
> > concerned.
> >
> > G
>
> In the case of OS X bundles, don't think of it like "installation". It's
> more like "finishing up".
>
> How about adding some logic to target_link_libraries that writes a file,
> similar to depend.internal, mapping the install-name of the linked libraries
> to their location (if a full path has been used for linking). This file
> could then be used by BundleUtilities.cmake. Probably one would need to
> black-list certain directories (such as /System/Library/Frameworks), or is
> this already done?
>
>
BundleUtilities avoids copying "system" files -- they are expected to be
installed everywhere by virtue of the fact that they "belong" to the OS.
Files in /System do not get copied in by default with the BundleUtilitles
fixup routines.

Most of our examples of using BundleUtilities occur at "make install" time
via cmake scripts, but you could just as easily use them as part of a
post-build custom command step on your bundle, as long as all of the
dependent pieces are ready to be assembled.

HTH,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20091216/890ac64c/attachment-0001.htm>