[CMake] cpack bundle generator qq

David Cole david.cole at kitware.com
Fri Jan 16 11:31:53 EST 2009


Tim,
Thanks for chiming in.

Did my suggestion about possibly just modifying the bundle generator to also
enable using the "make install" tree as is make sense to you, or does it
seem like that should be a separate CPack generator?


David


On Fri, Jan 16, 2009 at 11:25 AM, Timothy M. Shead <tshead at sandia.gov>wrote:

> 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
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090116/1c18a7f8/attachment.htm>


More information about the CMake mailing list