The problem that I was trying to solve with the bundle generator was how
to install complex systems in a cross-platform way. Assume that you
have an application "foo" that is run by end-users, plus helper
applications "a" and "b" that are run indirectly by foo, and third-party
dependencies. You want to package everything in a consistent way on all
platforms. So you do
INSTALL(TARGET foo a b DESTINATION bin)
INSTALL(FILES dependencies DESTINATION lib)
With *nix and NSIS, this is straightforward and works fine. With
bundles, it's trickier. You don't want separate bundles for foo, a, and
b in this case, you want a single bundle where foo is what gets executed
when the user double-clicks on it, but a and b are included where foo
can find them. That immediately eliminates the MACOSX_BUNDLE approach
off-the-bat, because it creates separate bundles for each executable.
Even if you omit MACOSX_BUNDLE for a and b, you still have no mechanism
to install them into the bundle created for foo. The same applies to
third-party dependencies.
Thus, the approach taken by the bundle generator is to create a single
bundle, populate its contents based on your CMake INSTALL commands, then
add the necessary metadata to define *which* binary is executed when
end-users click on the bundle, then create the dmg.
I've never run across a dmg that contained multiple bundles, but adding
a feature to create multiple bundles based on components sounds like a
good idea. I guess that in an ideal world you would like to set
per-component properties (if there were such a thing) that could be used
by the bundle generator to setup the bundles, but other workarounds
should be possible.
Cheers,
Tim
--
Timothy M. Shead
Data Analysis & Visualization (1424)
Sandia National Laboratories
505-284-0139
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
