Hi, Bradley Nelson: > 1. Ability to incrementally transition on Windows. It took us about 6 > months to switch fully to gyp. Previous attempts to move to scons had > taken a long time and failed, due to the requirement to transition while > in flight. For a substantial period of time, we had a hybrid of checked in > vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch.
> 2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on > Windows, to generate vcprojs which resemble hand generated projects. It > doesn't generate any Makefile type projects, but instead produces msvs > Custom Build Steps and Custom Build Rules. CMake generates some pre/post-project building steps to the vcprojs (or an additional project), where it runs a CMake script. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? > 4. Strong notion of module public/private interface. Gyp allows targets to > publish a set of direct_dependent_settings, specifying things like > include_dirs, defines, platforms specific settings, etc. This means that > when module A depends on module B, it automatically acquires the right > build settings without module A being filled with assumptions/knowledge of > exactly how module B is built. Additionally, all of the transitive > dependencies of module B are pulled in. This avoids their being a single > top level view of the project, rather each gyp file expresses knowledge > about its immediate neighbors. This keep local knowledge local. CMake > effectively has a large shared global namespace. All dependencies are generated from CMake too (if declared correctly) and the "global namespace" isn't a real problem IMHO. > 5. Cross platform generation. CMake is not able to generate all project > files on all platforms. For example xcode projects cannot be generated from > windows (cmake uses mac specific libraries to do project generation). This > means that for instance generating a tarball containing pregenerated > projects for all platforms is hard with Cmake (requires distribution to > several machine types). Is there any demand for such a feature? Why you can't distribute the CMake file only? > 6. Gyp has rudimentary cross compile support. Currently we've added enough > functionality to gyp to support x86 -> arm cross compiles. Last I checked > this functionality wasn't present in cmake. (This occurred later). Supported since 2.6: http://www.cmake.org/Wiki/CMake_Cross_Compiling. - Patrick _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
