Re: Is there any way to use ARC in 32-bit?

[Richard Frith-Macdonald]

On 30 Jan 2015, at 07:34, David Chisnall <theraven@sucs.org> wrote:
> 
> On 29 Jan 2015, at 09:10, Richard Frith-Macdonald 
> <richardfrithmacdonald@gmail.com> wrote:
>> 
>> Different worlds ... on FreeBSD that's roughly 2:1 cmake to autotools, but I 
>> guess it looks different in non-bsd systems.
> 
> No.  This is the FreeBSD *ports* collection (i.e. third-party code, most of 
> which originated on Linux and other *NIX systems).  KDE is not a FreeBSD 
> project, for example, neither is MySQL.  According to OpenHub, CMake has 129 
> developers - that's more people working on *a build system* than on GNUstep.  

No offence intended, but it seems that you don't really get this at all ... 
sionce you keep trying to compare gnustep-make with cmake in some way and they 
are actually doiing very different things.

gnustep-make is a relatively high-level tool to make it easy for people to 
build/install gnustep apps/tools ... it sits above two other tools (autoconf 
and make) and provides a consistent higher level structure to those tools for 
use building gnustep apps, tools, frameworks etc ... things which have a 
particular directory structure etc.  It does this by providing makefiles which 
are used to build/install everything in a certain layout.

As far as I know cmake is a lower level tool (much more comparable to 
autoconf).  While it may be possible to configure cmake in some way so that the 
makefiles it produces duplicate the functionality of the makefiles from 
gnustep-make, I have no idea how and have never seen a cmake advocate describe 
how it could actually be done, let alone volunteer to do it.

> Rather than build on their work, we continue to maintain something that:
> 
> - Conflates configuration with building.

autoconf/configure does configuration, make does building ... the separation 
seems a bit cleaner/clearere than with cmake.

> - Locks you into a single build mechanism (no XCode project generation, for 
> example, so I have to maintain two build systems for anything that I want to 
> use with GNUstep and Cocoa).

Any system 'locks you in' in the sense that, if you use that system then you 
aren't using another one.  There's no special extra lock-in with gnustep-make 
other than the fact that it makes things easy for people (so they are less 
likely to put a lot of work into doing things a harder way) to just have 
everything built/installed in the right places on a GNUstep system.  You can 
build on OSX with gnustep-make, but it lacks the integration/ease of use of the 
native tuools, in the same way that building in a gnustep environment with 
cmake lacks the integration/ease of use there.

> - Has no well-defined extension mechanism.

I suspect this comment is from the point of view of using cmake, which needs a 
special extension mechanism since it's inherently opaque and fixed (being 
compiled code).
Where we are working always with interpreted source code rather than compiled 
code, things are easier to extend.  So while there are specific 
config/extension options you also have the generic mechanisms of simply adding 
new autoconf tests and adding new makefile fragments.  I guess these are not 
'well defined' in the sense that they are implicit in the documentation of the 
macro language and make language rather than explicitly stated as extensions.

> - Has no uses outside of the GNUstep ecosystem.


Well that's kind of the point really ... making it easy to build/install 
GNUstep apps to live in the GNUstep ecosystem.


Anyway, I really, really didn't want to get drawn into the old  cmake/autoconf 
argument (since I consider autoconf the lesser of two evils rather than 
anything actualy good).
Rather, I'd like to encourage people to discuss how best to support both 
traditional and objc2 style builds in gnustep-make (in the absence of any 
realistic proposal to reproduce all the gnustep-make ease of use and 
functionality using something other than autoconf/make).