Re: gnustep-base code freeze

[Nicola Pero]

> Did these get added in the end?  Without them, -make is likely to be broken 
> in a number of configurations.

I added them.  Testing is welcome.

I guess gnustep-make is ready for release (subject to testing, and fixing the 
-Wl,-r / -mno-relax issue). ;-)

A last bit I was thinking of doing was deprecating objc.make.  objc.make is 
meant to be used to compile
Objective-C programs (not libraries) without the use of any Foundation library.

This is not really that useful, and it will become increasingly hard to 
support.  Let me explain.

At the moment, using your own custom libobjc (for example, but not limited to, 
libobjc2) is quite
cumbersome:

* configure/make/make install in gnustep-make (and you need to have some sort
  of libobjc already here to bootstrap the process!)

* make/make install in your own libobjc

* configure/make/make install in gnustep-make (again!) to detect the new libobjc

* configure/make/make install in gnustep-base

It would be good to remove the requirement to reconfigure/reinstall 
gnustep-make after installing
your custom libobjc to make the process easier.

This suggests the following setup:

* gnustep-make's configure would contain checks for compiler capabilities that 
do
  not depend on the runtime, so that we know what flags to use when compiling 
C/ObjC
  (required to compile custom libobjcs properly!)

* gnustep-base's configure would contain checks for runtime capabilities, so if
  you change your runtime, even significantly, you still don't have to
  reconfigure/reinstall gnustep-make.  You just go straight to gnustep-base as
  gnustep-make does not depend on the runtime. :-)

I did follow this logic when implementing the checks for the Objective-C native
exceptions.  So, gnustep-make checks that the compiler supports them (but you 
don't
need a runtime installed with support for them yet), then gnustep-base checks 
the runtime
support (and can still disable native exceptions if no satisfactory support is 
found).

At the next release (too late for this one) we'll do a similar change for the 
threading
flags and eradicate any dependencies of gnustep-make on the runtime, so we can 
simplify
using custom ObjC runtimes. :-)

But, the big disadvantage is that objc.make becomes harder to support; once 
gnustep-make
contains no code that depends on the runtime, it wouldn't know what flags to 
use to
compile/link with that runtime if gnustep-base is not used, so objc.make makes 
no longer
particularly sense.

As nobody is using objc.make as far as I know, I was thinking of deprecating it 
(not
removing it, just deprecating it) in this release.  It's important to deprecate 
early
because we don't remove deprecated things from gnustep-make for many many 
years. ;-)

The removal of objc.make doesn't mean we don't want to support building with 
other
ObjC libraries or things; if anyone has any such requirement, please talk to 
me.  It
would make sense in most cases to reuse library.make, tool.make etc. and use a 
custom
additional makefile fragment in the way that gnustep-base does it, which is 
quite easy
to setup.

Comments / suggestions welcome! :-)

Thanks