[CMake] Bundle Generator conflicts with MACOSX_BUNDLE

Timothy M. Shead tshead at sandia.gov
Fri Oct 31 12:18:51 EDT 2008


Mike Arthur wrote:
> On Thursday 30 October 2008 18:43:04 you wrote:

> Basically what I mean is, if the CPACK_BUNDLE_STARTUP_COMMAND is simply
> copied, how can you do install_name_tool operations on it without disrupting
> the build tree?

> In my humble opinion the CPACK_BUNDLE_STARTUP_COMMAND and possibly also the
> Info.plist should be manually installed by "make install" to allow them to be
> modified by INSTALL(CODE/SCRIPT) commands, such as to do install_name_tool
> fixups.

My intent is to create a system where you use the same set of INSTALL() 
commands across all platforms.  Typically, that means installing your 
executable with something along the lines of

INSTALL(TARGET myapp DESTINATION bin)

... which puts the executable in the Contents/Resources/bin directory of 
your bundle, after which you can use INSTALL(CODE/SCRIPT) to do whatever 
you need to do to it.

Of course, you still have to provide a mechanism so the executable can 
be located when your user double-clicks your bundle.  That's where 
CPACK_BUNDLE_STARTUP_COMMAND comes-in ... it copies a bundle-specific 
file into the Contents/MacOS directory.  That file could be a symlink to 
the actual executable, or a startup script.  Note that it is *never* 
intended to be the executable itself.

The alternative would be to manually install the executable to 
Contents/MacOS, as you suggest.  You could do that today by changing 
your INSTALL() command to

INSTALL(TARGET myapp DESTINATION ../MacOS)

... which should work, but is suboptimal for several reasons:

* You're no-longer using the same INSTALL() command on all platforms.

* You have to make sure that the installed executable is named correctly 
based on the bundle name.

* Although a relative DESTINATION path seems to work OK today, I'm not 
sure whether it will / should be allowed by CMake in the long-term.  You 
can imagine that end-users would be pretty upset if a poorly-written 
build scattered files around outside their chosen CMAKE_INSTALL_PREFIX.

This is why I think the ideal solution is to:

* Provide CPACK_BUNDLE_STARTUP_COMMAND for those people who need to use 
startup scripts.

* Provide a mechanism to automatically generate a symlink for everyone else.

Cheers,
Tim



More information about the CMake mailing list