Re: Some random thoughs and questions on the future of GNUstep

[Sheldon Gill]

Nikolaus Waxweiler wrote:
> Adopting CMake (or better: Replacing GNUstep Make)
> --------------------------------------------------
> [snip]
> on maintaining GNUstep Make and that's the problem: GNUstep Make is a
> build system in its own right which needs to be maintained somehow.
> The (obviously) smarter thing to would be to let others do the coding,
> especially if that piece of software is their main development focus.

There would still be maintenance, I'm afraid. Just like there is maintenance 
with gcc that has to be done. Maybe we could get some nice features with less 
effort but there'd still need to be maintenance.

> - CMake is a replacement for the whole Autotools suite, yet rather
>    [snip]
>    guess this will make it a bit easier to check for external
>    dependencies compared to GNUstep Make.

GNUstep-make doesn't deal with this issue: autoconf does. As an autoconf 
replacement, CMake is very nice.

Application, library and framework authors are free to use whatever build 
configuration tool they wish. Turns out that it is rarely needed.

> - As mentioned on
>    http://wiki.gnustep.org/index.php/Roadmap_to_Windows#Make, GNU make
>    is very unixy. CMake generates files for Windows-native build tools,
>    making Windows developers' lives a bit easier.  Building the core
>    libraries on Windows might also be facilitated if we switch from
>    Autotools.

Well, *I* wrote that so let me respond.  The issue mainly is that gnustep-make 
as it currently is, assumes a very POSIX environment which Windows just isn't.

So you need a POSIX-ish shell in which to do it. It would be good if 
gnustep-make would run under the command shell. It would also be very good if 
make could handle paths and files which have spaces in their names. Those two 
things are the real problems. Hmm... maybe I should update the wiki. I did that 
as a bit of a quick brain-dump a while ago.

The core libraries do build on Windows already. Have done so for quite some 
time.

As for "generates files for Windows-native build tools, making Windows 
developers' lives a bit easier" you don't seem to realise that gcc is the only 
Objective-C compiler available. It does a pretty good job and I don't believe 
there is any compelling reason to move away from it.
Windows native build tools won't help. Besides which, there is the freedom 
issue.

> - CMake works out dependencies of files automatically, so you can run
>    several concurrent build processes ("make -j 4"). I heard there were
>    problems in that area with GNUstep Make.

This is a nice feature of CMake

> - It includes CPack, a tool for automatically packaging files to
>    install (.tgz and such). It even supports generating installers for
>    Windows and Mac OS X if I understand correctly:
>    http://www.cmake.org/Wiki/CMake:Packaging_With_CPack.  This should
>    fulfill wish #2 (and maybe #3?) on
>    http://wiki.gnustep.org/index.php/GNUstep_wish_list.  Might be
>    possible to extend it to fulfill #4.  AFAIK it's currently in beta,
>    .rpm and .deb support will come later.

> - It includes CTest, a tool for running tests and submitting the

GNUstep has a testsuite. It is really easy to run. Doesn't require much setup, 
either.

Testing is really a much bigger issue and CTest is essentially a wrapper script 
to invoke "make test" and send the output somewhere if you want. It doesn't 
really address the bigger issues in testing.

> Unfortunately, there are also some downsides.

The big upside for GNU make is that it's available everywhere gcc is, which 
means everywhere you could consider Objective-C.


Regards,
Sheldon