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