Re: Cross-compiling GNUstep?

[David Chisnall]

On 30 Dec 2013, at 07:23, Richard Frith-Macdonald <address@hidden> 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