[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-compiling GNUstep?

From: Andrew Pinski
Subject: Re: Cross-compiling GNUstep?
Date: Mon, 30 Dec 2013 22:16:12 -0800

On Mon, Dec 30, 2013 at 2:26 AM, David Chisnall <address@hidden> wrote:
> 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).

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.

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
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]