I'd like to suggest a new guideline for the CMake files to encourage consolidation of build systems between ports, specifically to discourage future ports from bringing in more build systems. The rule of thumb is as follows: "Source lists, include paths and generators that aren't specific to a single port should be kept somewhere they can be easily reused by new and existing ports." In practice, this would mainly affect WebCore/PlatformEfl.cmake but there are bits of PlatformWinCE.cmake that look generally useful as well. Where would the portable source lists go? If the feature relates to a third party library backend (Cairo, Pango, ICU, Curl, Soup, GStreamer etc.) I'd suggest Platform.cmake files in line with the existing Platform*.cmake pattern, keeping the core CMakeLists.txt clean. As for features like the create_jit_stubs ARM generator in JavaScriptCore/PlatformWinCE.cmake, this should probably have gone in JavaScriptCore/CMakeLists.txt to begin with. I think this gentle approach has a better chance of working than previous attempts to replace eg. the GTK+ build system with CMake wholesale. Will roll a patch if there are no objections, but I've been out of the loop for a bit so putting this to the current maintainers. (Bug #72238 has some related comments.)
(In reply to comment #0) > I'd like to suggest a new guideline for the CMake files to encourage consolidation of build systems between ports, specifically to discourage future ports from bringing in more build systems. > > The rule of thumb is as follows: > > "Source lists, include paths and generators that aren't specific to a single port should be kept somewhere they can be easily reused by new and existing ports." > > In practice, this would mainly affect WebCore/PlatformEfl.cmake but there are bits of PlatformWinCE.cmake that look generally useful as well. > > Where would the portable source lists go? If the feature relates to a third party library backend (Cairo, Pango, ICU, Curl, Soup, GStreamer etc.) I'd suggest Platform.cmake files in line with the existing Platform*.cmake pattern, keeping the core CMakeLists.txt clean. I agree on this, but I can't say what has to go in which file, since many code parts are mixed up in different files. IMHO to fullfill this requirement we need to "cleanup" some/many of the CPP files first. I also don't know what makes sense to share at the moment. That's the reason why I'd suggest to change the ports to CMake with the current approach and refactor the common parts out of the files when it becomes clearer what can be shared. (This is at least my personal plan) > As for features like the create_jit_stubs ARM generator in JavaScriptCore/PlatformWinCE.cmake, this should probably have gone in JavaScriptCore/CMakeLists.txt to begin with. Not sure on this point, since the call is specific for the WinCE ARM assembler and the other ports use inline assembler. > I think this gentle approach has a better chance of working than previous attempts to replace eg. the GTK+ build system with CMake wholesale. Are there any interests in switching the GTK+ port to CMake? I already did some inital patches for WinApple (bug 72816) and Wx (bug 73100), but found no time to improve them since then. > Will roll a patch if there are no objections, but I've been out of the loop for a bit so putting this to the current maintainers. Every work on this is welcome.
(In reply to comment #1) > I agree on this, but I can't say what has to go in which file, since many code parts are mixed up in different files. IMHO to fullfill this requirement we need to "cleanup" some/many of the CPP files first. I also don't know what makes sense to share at the moment. That's the reason why I'd suggest to change the ports to CMake with the current approach and refactor the common parts out of the files when it becomes clearer what can be shared. (This is at least my personal plan) I'm playing around with a local port to see how the porting layer is doing, so have an idea where to find the low hanging fruit. > > > As for features like the create_jit_stubs ARM generator in JavaScriptCore/PlatformWinCE.cmake, this should probably have gone in JavaScriptCore/CMakeLists.txt to begin with. > > Not sure on this point, since the call is specific for the WinCE ARM assembler and the other ports use inline assembler. At least one other port, Qt, used this generator when targeting WinCE IIRC. Probably doesn't matter so much though, you're right. > > > I think this gentle approach has a better chance of working than previous attempts to replace eg. the GTK+ build system with CMake wholesale. > > Are there any interests in switching the GTK+ port to CMake? I already did some inital patches for WinApple (bug 72816) and Wx (bug 73100), but found no time to improve them since then. We tried in the GTK+ port to avoid adding a new build system, but CMake was removed from SVN and replaced with QMake. Then QMake couldn't handle build dependencies at the time. And pulling in a competing UI toolkit is bad politics. Bakefile didn't really work out either, because nobody had heard of it. After the run of bad affairs, autotools was a relief. For developers coming from places Mozilla where you hand edit scripts describing every detail of your machine, OS and libraries before it will build, a big mindshare win. At first GTK+ autotools and Mac sourced the same generator Makefiles, but even those ended up getting duplicated in GNUMakefile.am. Then at some point someone had the idea of listing every permutation of .idl, .cpp, .h generated file in triplicate for no particularly good reason. make dist / distcheck is a useful convention but now distributions maintain git clones and everyone else goes for TOT, tarball machinery is less important. The reasons for GTK+ having its own build system are long gone and there's CMake nowadays so I'm not sure why GTK+ is still hanging on to autotools. Ultimately I think it's up to the distributions to have the last say as they have to deal with the fallout if CMake can't detect headers on Debian userspace with a Hurd kernel on m68k or whatever they are stuck supporting. On the GNOME side, it might impact jhbuild / release engineering. Can be dealt with I'm sure. Cross-compiling will need to work though, ideally without boilerplate. Don't know what the CMake status on that is. Has anyone tried building WinCE on Linux / CMake using CeGCC? > > > Will roll a patch if there are no objections, but I've been out of the loop for a bit so putting this to the current maintainers. > > Every work on this is welcome. Anyway, veered off topic. Love your work on WinCE, it's gone from the sidelines to being one of the cleanest in tree.
I think the CMake build system has now met the guidelines of this bug.