On 30 Dec 2013, at 07:23, Richard Frith-Macdonald <richardfrithmacdon...@gmail.com> wrote:
> In my experience CMake is far more of a burden because it doesn't have the > years of documentation development that autoconf has, and (more importantly > to me) because its a monolithic C program. You need to get the source and > figure out what it's doing, and that's just easier to do with the configure > script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. My main attraction to CMake, however, is not CMake itself as much as Ninja, which dramatically improves life when doing a lot of incremental builds. LLVM has both CMake and autoconf+make build systems. After changing one file, the Ninja files that CMake generates can do an incremental build in less time than it takes for the GNU Make build system to determine that it has no work to do if you don't change any files. Oh, and when it needs to reconfigure, rerunning cmake takes about a fifth of the time that running ./configure takes, even though it's actually doing more work (configure just sets some flags for some hand-written Makefiles to use, cmake generates the build system). For OS X users, there's a nice CMake GUI that lets you generate XCode project files, which I imagine would be very attractive to users wanting to run GNUstep code on that platform. The generated XCode files aren't perfect, but they're a lot easier for OS X developers to use than GNUstep Make. Oh, and they already support building .app and .framework bundles on OS X, so it should be possible to reuse some of this code, which might even give us some existing OS X applications running on GNUstep for free... That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. David -- Sent from my Cray X1 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev