On Monday, April 22, 2013 08:22:50 AM Brian Milco wrote: > > Does this workflow in your MacAppStore generator include anything that > > prevents making a .pkg for OS X Installer? > > From the stackoverlfow link below, the person says App Store submissions > > follow different rules. Do you know what those differences are? > > As I've never created an OS X Installer I really don't know. > > > it would be nice to at least start off well and go in the right > > > > direction. > > Agreed. > > > I'm not convinced that an implementation based on the Bundle generator way > > is the right start. > > I started with the Bundle generator because that's what I have been using > to distribute my application for the last couple of years. > > > Maybe I wasn't clear before. CMake can already do .app creation. > > I had forgotten that. I had gone with the Bundle generator two years ago > because I was able to get it working how I wanted quickly and easily. I > based my new generator on it because with the exception of the final dmg vs > pkg packaging they should build the same .app folder structure, and I > wanted both distribution methods to share the package creation and code > signing code. > > I spend some time this weekend looking at the implementation of the new > generator, right now the code signing is in the DragNDrop generator which > makes it available for all derived classes, allowing it to be used for both > Mac App Store signing, and also for developer code signing required by the > default behavior of OS X 10.8 Gatekeeper for non-App Store applications. > > I would like to hear your thoughts on what you think is the best approach > to structuring the code. > > Thanks, > Brian
And I'm intrested in other people's thoughts too. I'm starting to think the code signing can be done with a cmake module instead of in the C++ cpack code. Being in DragNDrop generator does not make it available to all cpack generators usable on Mac. The signing of the pkg would still have to be in cpack. As a cmake module, it could be used at packaging time by having a install(CODE ...) in the CMakeLists.txt file. It is my understanding that cmake modules are generally preferred over c++ code, where possible. So my suggestion now is to have code signing in a cmake module, and the new cpack generator be a class derived from cmCPackGenerator. Without the Bundle generator behavior, because people should be able to use any cpack generator without modifying the CMakeLists.txt when switching generators. So, that's my 2 cents. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
