Daniel Reichert wrote:
First of all you have to consider that some of our needed IDEs (thinking about Xcode/VS) are exlusivly running on different OS, which means we don’t benefit from compiling both once a time which seems to be one benefit of CMake (Am I right with this suggestion?).
That’s the whole point of CMake, that you describe the logical structure of a software project, including all its dependencies, independent of the source and target OS and have it generate IDE projects available on the source platform. E.g. on Windows, you can choose VS, Eclipse, regular Makefiles, etc, while on MacOS, you could use Xcode, Eclipse, Makefiles, Code::Blocks, etc, while on Linux, you could use Eclipse, Code::Blocks, Makefiles, etc. Some IDEs such as NetBeans or Qt Creator even support CMake natively. I agree that for deploying to mobile platforms, you are restricted to whatever deployment toolchain you have, which restricts us to Xcode on MacOS for iOS and Eclipse on Linux/MacOS/cygwin for Android, but given that all of these combinations are supported by CMake out of the box for native compilation and that CMake can easily handle cross-compilation, it should be possible to get CMake working and handle the code infrastructure in a platform-agnostic way.
Furthermore our Platforms are much more different than they would be if we just would have Unix Systems on the one and Win Systems on the other hand (for which CMake mostly seems to be made for (again I’m not sure if this is true)).
The build and deployment toolchains for all deployment targets supported by cocos2d-x are also restricted (if you can call it that) to Unix (including Linux and OSX) and Windows systems. CMake runs on these same systems.
We not only have very different OS we also have much different hardware with a range from your XBox over your PC to your Smartphone, which needed to be treated very individually.
Not from a userland code perspective, otherwise cocos2d-x wouldn’t make any sense as a project. The hardware differences should be (and of course are) handled by the cross-compiler and any libraries (e.g. cocos2d-x) that abstract away the hardware. If you write standards-compliant C++ code, you should not have to deal with hardware differences unless you specifically call platform-specific APIs. If any cocos2d-x project is tied to a specific target from the start, I might as well just use that target’s native toolchain.
Furthermore you are not working in the “normal” working chain of your target system (which is especially important because you can test one platform on the same device you are developing (PC) while another needs to be emulated and/or remotely debugged (Smartphone).
Define “normal”. I don’t consider cross-compilation abnormal. And, as you said, you can easily test on emulators, which is why they exist for both iOS and Android development, although ultimately you must deploy and test on the actual hardware, anyway. I don’t see how that impacts a build system.
Also Xcode doesn’t seem to be listed under the native build tools supported by CMake.
Run on my MacBook Pro:
localhost:~ jh$ cmake —help
cmake version 2.8.9
The following generators are available on this platform:
Ninja = Generates build.ninja files (experimental).
Unix Makefiles = Generates standard UNIX makefiles.
Xcode = Generate Xcode project files.
CodeBlocks - Ninja = Generates CodeBlocks project files.
CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Unix Makefiles
= Generates Eclipse CDT 4.0 project files.
KDevelop3 = Generates KDevelop 3 project files.
KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files.
So instead of working with CMake i again suggest to just open default cocos2d-x projects in your target systems IDE (using the cocos2d-x templates) and adding your special code and even special folder structure via (for example) git. In this way you have the benefits of being in the default production chain of your targets system while sharing the same code easily and remotely over different systems any time everywhere even with team support. On the down side it means a bit more fiddling with your IDEs.
I consider “fiddling with your IDEs” a huge downside, if I simultaneously want to deploy the same code base on both Android and iOS. I really resent the notion that I’d have to check in IDE-specific files into my code repository, and that I’d have to manually add files to, say, Xcode for iOS deployment and tweak Android.mk for Android deployment. I want my students to be able to concentrate on the game design issues and not having to know the ins and outs of any potential target platform. At the same time, I want to be able to deploy on multiple platforms simultaneously, which is the whole point of a cross-platform framework to begin with, otherwise I could just stick with the native frameworks.
Are my critics justified or did i just don’t get how CMake works?
Think of CMake as a build and configuration system, not necessarily as an IDE project generator. The restriction to certain IDEs in the case of cocos2d-x stems from the limitations of the target platforms and the choices the people in charge of those platforms made.
HTH,
Jens
