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/ _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
