On 9/23/14, Florent Castelli <florent.caste...@gmail.com> wrote: > Hi! > > My company is organizing soon a hack week where each employee is able to > work on any project he wants. So, I've decided to work with Cmake and > improve support for iOS to help the product team getting rid of manual > project files, constant merge conflicts and bad project file documentation, > while improving our tooling possibilities (all that with Cmake!). > > I've had a quick look at the first issue that popped into my mind the other > day and fixed try_compile by adding another variable to set the executable > type in the generated project (it has to be MACOSX_BUNDLE) and fixing the > search path for the resulting binary. > So this is now working... Providing we are targeting the simulator. > Due to the nature of Xcode projects that can easily target either the > simulator or devices, thus using different compilation flags, the resulting > projects aren't working in both case. There are conflicts between some > options like the minimum iOS version target and the minimum iOS simulator > target for example (which you need to build the try_compile binaries > without signing them). > Also, the Xcode support is very OSX focused and all variables have MACOSX > in their name, which is confusing. > > So, has anyone worked on similar issues and can suggest a way to progress > and improve support for iOS? > In the end, I'd like to have a working Xcode project with separate settings > for both simulator and device, Cmake compiler flag detection working, and > possibly later Make/Ninja projects working too. > > Regards, > /Orphis >
This is off the top of my head, and its late... Some context...I'm developing a new SDK for game developers. I've been spending a lot of time with the generators (Windows, Linux, Mac, iOS, Android, and playing with Windows Phone recently). CMake is the best game in town for handling all these platforms. But there are also a ton of things that annoy me. My goal is to help people build apps they can ship, but much of CMake's thought process is about building apps locally for your system and the work flow isn't correct in my opinion. I've done a lot to address these short-comings and I hope to clear some time to talk about all this and share my changes in the near future. (Especially the Android stuff...I had to build a lot of crap to make that work and I would like to fold that back into the CMake core because it is evil.) As for iOS (and some Mac), one of my peevs is that the application bundle process doesn't happen as part of the build. For a normal Mac/iOS development, you always rebuild your code and your application bundle. CMake treats this as two discrete steps so what you develop/test is different from what you ship. (And incidentally in the Visual Studio case, I discovered it is impossible to launch your app via the debugger because of this too.) Additionally, the iOS/CMake stuff is flakey about letting you switch between device and simulator. You shouldn't have to generate a completely different project to test between the two. This is not how iOS developers work nor how the Xcode toolchain is designed. (And now that we have 32-bit and 64-bit versions of both, it's ridiculous.) I some how got mine to the point where I can switch targets in the same project, but it's flakey due to the way CMake injects paths/values into the Xcode project. It isn't the same exact values as Apple, so somethings like finding frameworks/libraries cause me to do some tricks. Also on that note, just getting CMake to pick the proper "Lastest SDK" value by default would be nice. It is hard coding some full path which seems to work in base cases, but causes me problems in other cases. I noticed when Xcode versions change, this often is the main culprit for new breakage. All the configuration options are blank for me. The Mac one works, but iOS is blank for me. This means thinks like all my optimization settings are the same (debug and release have the same values). I can set these values manually, but I have only been able to do it to my own targets explicitly. My attempts to set the values globally (at the root) have not succeeded. I still haven't dealt with launch images and icons. A proper sized launch image is required to get the iPhone 5 and iPhone 6 "tall" resolutions without letterboxing. I'm not sure what the right thing to do here is with CMake. I'm doing my own application bundling to some degree. As I said, CMake's normal process goes against the grain of the normal workflow so I changed it to behave like the real thing. I'm having trouble remembering, but I think the CMake/Mac had better handling than CMake/iOS. CMake was doing some stuff for me better than iOS, but I don't fully remember. (May have something to do with listing resources as part of the target.) But one place I found CMake to be really annoying was with nested directories and also symlinks. Copying a framework into a bundle is a good example because it has both. And ideally, you only want to do it when there is a change. (I think I got lazy and call rsync in some places since I know it is installed on Mac.) Codesigning for both Mac and iOS I haven't figured out yet either. On iOS, you have development and distribution keys. On Mac, you also have Mac App Store vs. GateKeeper. Xcode normally gives you a display to let you see and configure important things like Sandboxing options, launch images, icon resolutions, code signing. But when going through the CMake generator, it doesn't show any of this stuff. I don't know why, but it's disturbing/scary (because it feels broken/fragile) and annoying. Maybe updating the underlying Xcode template CMake uses will help? I would like CMake's install/packaging system to work seamlessly with the built in archiving system which is what people use to prepare an iOS app for submission to the App Store. There is a bug I sometimes hit where the generated Xcode project causes the "Indexing" phase to get stuck and I have to kill Xcode. And when it happens to me, it keeps happening. This really scares me, but I can't reliably reproduce it. Xcode 6 seems to have improved the problem for me (so far). For building libraries instead of applications, iOS 8 now has 3rd party framework support (to support their new plugin system). I have not tested this. But the framework layout is different than in Mac (similar to how the .app bundle layout differs between iOS and Mac). I'm guessing this will need to be adjusted in CMake. Also, FYI, flat dylibs are not supported as far as I know...only frameworks. Also, I think the @rpath stuff is still important, and I read that Apple has now split the setting that was once the "install path" into two separate entries, where the new entry is just for the rpath. (Install path never made a lot of sense the way Apple does things since there is never really an install path.) Yes, it would be nice to build Universal binaries with simulator and devices in the same fat binary, but Apple doesn't do this for you, and I don't know if CMake should do this for you either. I saw on the Xcode list, one senior Apple engineer was being difficult when pressed on this issue. I think Apple is trying to leave open the possibility that there could be an x86 device target some day, in which case it would conflict with an x86 simulator target. Annoying. Currently, I just lipo everything myself manually and say screw it. 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-developers
