[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