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

[Richard Frith-Macdonald]

On 30 Jan 2015, at 10:08, David Chisnall <theraven@sucs.org> wrote:
> 
> On 30 Jan 2015, at 09:40, Richard Frith-Macdonald 
> <richardfrithmacdonald@gmail.com> wrote:
>> 
>> 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.
> 
> They are tools used to build.

A builder's trowel and a tunnel boring machine are tools used to build ... 
doesn't mean they are similar or doing really similar jobs.

>> 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.
> 
> It sits above autoconf?  How do I generate autoconf configuration scripts 
> with GNUstep make?  At best, it sits alongside autoconf, because you have to 
> use both (and they don't really play together well).  

High level and low level ... different layers of abstraction.  It's not as if 
you *run* gnustep-make ... rather it's something you configure and then 'make' 
uses the resulting makefiles to do things.

autoconf/configure is used to find out about the system and configure things 
... a tool addressing a low level task
similarly make is a relatively low level tool, extended with makefiles from 
gnustep-make

So gnustep-make leverages those tools (in particular make) to do things like 
manage subversion repositories and versioning, manage documentation, make sure 
everything is installed in the right place, build packages etc.
sure it is used to build, but the actual building is just part of it ... and 
fundamentally the building is done using make and can be extended using make 
rules.

This is why I put cmake on the level of autoconf/make for comparison purposes 
(and also why I view a war between those two systems with distaste; while I 
have a preference, I don't like either very much) ... it's not attempting to do 
the high level ease-of-use stuff.

I get that you hate gnustep-make, don't want any of the higher-level 
functionality it provides, and would like to use cmake for the basic build ...  
but unless someone like you can provide a re-implementation of the higher level 
stuff in conjunction with cmake (a gnustep-cmake package I guess), any switch 
is unrealistic.

Also, to try yet again to get back to the point:  whatever the underlying build 
tool,  we still want to decide how to support different setups to make things 
work well for everyone.

We have a (shrinking) majority using gcc to support, and a substantial 
(growing) minority using clang.

I suggested an idea for having two supported setups for this  ... so far no 
response.

We have people who want to target gnu/linux and windows, but might want to 
support OSX too, and we have people from OSX/BSD who tend to want to use Xcode.

People who want to work in linux and target OSX can currently use gnustep-make 
in both environments.
People who want to work in xcode and target linux/windows have a hard time of 
it ...  I think Greg may have made progress there though, converting an xcode 
project to make files.