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

[David Chisnall]

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.

> 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).  

Aside from GNUstep itself, there are very few projects using autoconf and 
GNUstep Make and for GNUstep the autoconf code does a load of redundant work, 
takes longer to run than the entire build, and doesn't properly inject itself 
into the generated dependency graph, so you end up having to gmake distclean 
periodically to get it to work, and when it does rerun itself it forgets all of 
the configuration options and you end up with a broken build.  

> 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.

It can produce Makefiles and XCode projects on OS X that can build .app and 
.framework bundles.  We could extend this to work with GNUstep if there were 
some interest in doing so.

>> 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.

CMake does the configuration and one of the pluggable back ends does the 
building.  With CMake, I can create Makefiles and Ninja files for building on 
*NIX (usually I use Ninja, as it's much faster for incremental builds, but make 
is nice for fallback).  The Makefiles that it generates are POSIX Makefiles, so 
they work with the various BSD Makes and Solaris Make as well as GNU Make.  

> 
>> - 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.

You're missing the point.  It locks you into a *build system* as well as a 
*configuration system*.  I can not use GNUstep Make to generate an XCode 
project on OS X or a Visual Studio project on Windows if I want to use one of 
these.  I can't use it to generate Ninja files on *NIX if I want to use that.

When I am working on an app that I want to run on OS X, I want to be using 
XCode, because it's a pretty solid IDE.  For all of the non-GNUstep projects 
that I work on where this is the case, I just ask CMake to generate an XCode 
project for me.  Now, this has some limitations (I can't add files to that 
project and expect it to work, for example), but I can edit code, build, debug, 
and so on from the IDE.  Then I can take the same source to FreeBSD and Linux 
and build with Ninja (or I can use Make / Ninja on OS X if I don't want to work 
with the IDE).

For the GNUstep-based projects that I work on, I have to keep a GNUmakefile and 
an XCode project in sync.  XCode projects are quite exciting in revision 
control systems, so this then makes collaboration less easy.  

>> - 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).

No, it's from the fact that every time I try to use GNUstep Make, I find that I 
want to do something that I can't do.  For example, adding rules to invoke edlc 
to compile Smalltalk code was a pain.  Even finding and running pkgconfig is 
not well integrated.

> 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.

And that's how you end up with a system that scares off new developers.

When I started developing with GNUstep, I found that the build system was the 
steepest learning curve.  After fighting it for years, I still cringe at the 
thought of starting a new project that uses GNUstep and having to go through it 
all again.

I was willing to put up with it back when there really weren't any good 
alternatives, but now there are.  Reinventing the wheel does not always result 
in a better wheel.

David

--
This email complies with ISO 3103