[CMake] cpack bundle generator qq

Mike Arthur mike at mikearthur.co.uk
Sat Jan 24 05:23:40 EST 2009


On Saturday 17 January 2009 01:40:27 Timothy M. Shead wrote:
> Agreed - as I mentioned before, I understand that if you don't have a
> bundle, running a GUI application out of the build directory is
> problematic (for those unfamiliar: your program runs, but the window
> manager doesn't provide any decorations for your windows, so everything
> gets stuck in the top-left-corner of the screen and you can't move /
> resize / close them).
>
> What I was leading-up-to was that we need to make a distinction between
> "build bundles" that are created as a convenience for running
> applications out of the build directory, and "package bundles" that are
> created as part of the packaging process.  For example, if you have
>
> ADD_EXECUTABLE(foo ... MACOSX_BUNDLE)
> INSTALL(TARGETS foo DESTINATION bin)
>
> I gather that there is some special-case logic in the install-generation
> code that handles installing the bundled binary, the auto-generated
> plist, etc.  Now suppose that the special-case code were removed, so
> that just the binary - even though it's bundled in the build directory -
> goes to the bin directory at install-time just as it would on any other
> platform.  With this behavior in place, you would avoid the
> "bundle-within-a-bundle" problem, and you would write package generators
> that would be smarter - i.e. duplicate much of the functionality of
> build-bundling by default, but allow sufficient configuration to handle
> more complex packaging scenarios.
I think it's worth look at the PackageKit generator which does this properly. 
I guess I just want to make sure that whatever is decided, moving on, there 
are clear and consistent ways to make bundles and you avoid the bundle within 
a bundle problem.

-- 
Cheers,
Mike Arthur
http://mikearthur.co.uk/


More information about the CMake mailing list