On Mon, Dec 30, 2013 at 2:26 AM, David Chisnall <thera...@sucs.org> wrote: > 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).
Yes it might be faster than autoconf/automake but it is less standardized things to do in cmake. I have played around with a cmake system in the last year and found it was horrible as the options that I needed to do for cross compiling was all different and did not always do the correct thing so I had to hack the files instead. autoconfig/automake has some nice standardized way of figuring out if an API and/or a library exists. When was the last time you did a cross of a library that was not autoconf'd? cmake was not designed for cross compiling or even fits in a GNU project. Yes autoconf has its issue (slow due to being a big shell script) but being slow helps the portability of it. Try building cmake itself, it is a hard thing to do really; worse than GCC. Thanks, Andrew Pinski > > 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev