[CMake] cpack bundle generator qq

[Michael Jackson]

I agree with David on this. At the end of the build there _should_ be  
a .app application (assuming that is what you chose to make) that I  
can double click and launch/debug. The .app bundle does _not_ have to  
include all the dependencies at that point but should be debuggable/ 
runnable. Xcode works this way so I expect CMake to generate Makefiles/ 
Xcode projects that do this.

    Now, actually getting that .app ready for deployment is another  
matter all together, usually consisting of at least a few more steps  
which CPack should do for us:

    Gather non-system dependent libraries, copy them into the .app  
bundle, change the "install_name" of the library and executable if  
needed.
    Copy other resources into the .app bundle
    Copy Documentation and other supporting files
    Copy "helper" apps if any
    ... There are lots more.. ....

Now Decide if you are going to use a Drag-and-Drop DMG or and actual  
installer.
Prepare either one.


It would be nice if all that were encapsulated in CMake/CPack with  
clear delineations about which one does what. (I Know most of this is  
in there but even I can't seem to get through it and end up just using  
a Shell script to prepare everything).

Just my 2 cents worth

-----
Mike Jackson


On Jan 16, 2009, at 5:13 PM, David Cole wrote:

> I have always been of the opinion that if you are building a Mac  
> bundle application, it should be complete as a bundle at the end of  
> the build. At the end of "make". Even before "make install".
>
> Now that may just be my ancient Mac-fanboy-forever bias showing  
> through, but if you're building a bundle application, then I should  
> be able to go to the build directory in the Finder and double click  
> the icon after the build is done. If I can't do that, it ain't a  
> real Mac bundle app. Period.
>
> So I think it is completely valid to expect that a Mac app be  
> bundled at build time.
>
> Just my personal opinion, though.
>
>
> :-)
> David
>
>
> On Fri, Jan 16, 2009 at 5:08 PM, Clinton Stimpson <clinton at elemtech.com 
> > wrote:
> Timothy M. Shead wrote:
> David Cole wrote:
> I vote for a new generator then. A Drag-N-Drop DMG generator ==  
> DDD? :-)
>
> I prefer this to changing the bundle generator behavior.
>
> Maybe just good documentation about the existing generators and what  
> sorts of assumptions they make would be a good place to start. I  
> think the main problem here is that people expect the "bundle  
> generator" to deal with bundles properly, when in fact, what it does  
> is create a bundle for you at packaging time. It's a name  
> overloading / human understanding problem... not a problem with the  
> code.
>
> I would nuance this to suggest that the current MACOSX_BUNDLE  
> behavior blurs the line between building and packaging, which causes  
> much of the confusion.  Arguably, a dmg+bundle IS-A package - so  
> creating a bundle in the build directory is the wrong division of  
> labor.  If there was NSIS-specific stuff that got created in the  
> build directory every time you specified WIN32_EXECUTABLE, we'd be  
> having the same sort of confusion on Win32.
>
> How do you see a "make install" fitting in?  I think you need the  
> application bundle by that time.
>
> Clint
>
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake