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

> 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 agree. For me it was complicated to understand how it works. No easy way of creating new projects so I copy/paste the gnumakefile and change the content. It's tricky to know where to add compiler and linker flags although this might not be only for gnustep make. I too have to keep track of two build systems because I code in Xcode and build and run the code on FreeBSD/Linux.

I would welcome some improvements that would bridge the systems better. Isolating developers in GNUstep world is not what we want to do. We want to make it easier to share code and projects with other systems.

Johannes Lundberg

On Fri, Jan 30, 2015 at 7:08 PM, 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.

> 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

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

From:	Lundberg, Johannes
Subject:	Re: Is there any way to use ARC in 32-bit?
Date:	Fri, 30 Jan 2015 20:46:04 +0900