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.<br>
<br><div>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.</div>
<div><br></div><div>Seems like that might be a good solution.</div><div><br></div><div>Anybody have time to work on such modifications / new class?</div><div><br></div><div><br></div><div>David</div><div><br></div><div><br>
<div class="gmail_quote">On Fri, Jan 16, 2009 at 11:01 AM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com">clinton@elemtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Michael Jackson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jan 16, 2009, at 10:06 AM, Mike Arthur wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Friday 16 January 2009 15:05:55 Clinton Stimpson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another question, can I have the bundle generator make another sub<br>
folder, then I put two .app bundles in there, then when the user opens<br>
the dmg, they see one folder they can drag to their /Applications which<br>
contains multiple .app's. But there's still the problem of specifying<br>
different plist, icons, etc... from global variables instead of just<br>
using the ones I already set on the executables.<br>
<br>
Or does it not make sense to create installers like this?<br>
</blockquote>
I think it makes sense, personally, but the Bundle generator doesn't support<br>
it. If you wanted to do it that way I guess I'd add component support (like<br>
the PackageMaker/NSIS installers support) to the Bundle generator.<br>
<br>
-- <br>
Cheers,<br>
Mike Arthur<br>
<a href="http://mikearthur.co.uk/" target="_blank">http://mikearthur.co.uk/</a><br>
</blockquote>
<br>
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.<br>
</blockquote>
<br></div>
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?<br>
<br>
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.<br>
<br>
Clint<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
_______________________________________________<br>
CMake mailing list<br>
<a href="mailto:CMake@cmake.org" target="_blank">CMake@cmake.org</a><br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>