I would recommend modifying the existing bundle generator to keep its current behavior for backwards compatibility *and* add to its behavior such that it can produce a drag-n-drop installer for your "make install" tree.
If that proves too difficult in terms of coding or seems otherwise unadvisable.... then I would say we should add a new "drag-n-drop bundle generator" to CPack that does the "/Applications" shortcut thing and places either a single folder of your make install tree or the contents of your make install tree next to the /Applications shortcut. Seems like that might be a good solution. Anybody have time to work on such modifications / new class? David On Fri, Jan 16, 2009 at 11:01 AM, Clinton Stimpson <[email protected]>wrote: > Michael Jackson wrote: > >> On Jan 16, 2009, at 10:06 AM, Mike Arthur wrote: >> >> On Friday 16 January 2009 15:05:55 Clinton Stimpson wrote: >>> >>>> Another question, can I have the bundle generator make another sub >>>> folder, then I put two .app bundles in there, then when the user opens >>>> the dmg, they see one folder they can drag to their /Applications which >>>> contains multiple .app's. But there's still the problem of specifying >>>> different plist, icons, etc... from global variables instead of just >>>> using the ones I already set on the executables. >>>> >>>> Or does it not make sense to create installers like this? >>>> >>> I think it makes sense, personally, but the Bundle generator doesn't >>> support >>> it. If you wanted to do it that way I guess I'd add component support >>> (like >>> the PackageMaker/NSIS installers support) to the Bundle generator. >>> >>> -- >>> Cheers, >>> Mike Arthur >>> http://mikearthur.co.uk/ >>> >> >> You may end up having to create a shell script to create your >> distribution. Have CMake configure the shell script appropriately and then >> have CMake run the shell script to move everything into the proper location >> when CPack runs. >> > > I've already done this, so when I do a "make install," I get all my bundles > with install names fixed, with prerequisites, etc... It works fine with > CPack/PackageMaker generator which also makes the top level folder to > contain all the apps, so it installs nicely except for a root ownership > problem. But it doesn't work with the CPack/Bundle generator since it tries > to re-bundle the bundles that I've already got. I guess I could take the > last two easy steps, make the /Applications link and the dmg myself. Seems > to me those two steps is all the cpack bundle generator needs to be doing, > and the rest of the work of creating the bundle be done by the "make > install" step. No? Maybe a new cpack/dmg generator that just takes what > make install gives, optionally adds a softlink such as /Applications, and > makes a dmg? > > I was impressed that what I had done to make a nice NSIS installer also > worked just fine with PackageMaker. I like that consistency. I didn't see > that with the bundle generator. > > Clint > > > > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
