On Tue, Dec 9, 2014 at 4:58 PM, Eric Wing <ewmail...@gmail.com> wrote:
> On 12/9/14, J Decker <d3c...@gmail.com> wrote: > > This is all handled by install. > > I already addressed INSTALL. I know you can change the directory. That > is irrelevant to the point which I already addressed. > > You gave a personal opinion about install... not sure that addresses it. > > > > > Sounds really like you're working to build a package, which install is > > intended to do. > > Another problem which I didn't make explicit was that Xcode's > codesigning and entitlements phase will not work with INSTALL because > it signs when you build via Xcode. And there are cases where you must > develop and test with codesigning and entitlements enabled, like > testing App Store purchases, Game Center, or want to use the new > built-into-Safari JavaScriptCore debugger if you have a JSContext in > your app. > > Also, iOS/Android/WinRT, the INSTALL target is useless. > Android It's not useless... it puts all the files in a correct place to be able to do manual packaging things. Massaging a system that's already been installed is a lot easier than pulling from sources scattered all over the build directory; and doesn't require a lot of custom macros and scripts to do the job. True; I had to write another cmake layer on top of the already existing projects which go to their install... and make some custom commands for 'install' and 'package' for android that pull from the one place just what it needs to stuff into the android directory... but those scripts were really simple since everything was already in a simple, known location after install. > > The INSTALL thing is a hack in my opinion that we as a community have > accepted as a solution. I'm now calling it out as a design problem in > CMake, especially as the winds have shifted to more platforms focusing > on shipping binaries than the former and now treat packaging as a > first class citizen. It is an impediment to the natural workflow on > those platforms, it is an impediment to people adopting CMake, and it > is an impediment to people wanting to deal with native languages > because build systems are too complicated. (The scripts I wrote are > intended to deal with all those things in a new middleware product I'm > developing and hopefully bring native crossplatform development to > people that otherwise wouldn't touch it before.) > > Your scripts would still only work for one target... since you'd have to pick one to build the rest of the package around, so if I have a build product that has a dozen utilities, rather than having one place they can all work from, I have now to either duplicate all files to all runnable targets or have a central one that would be the only one to work. This is more of a hack. > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
