[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-base code freeze
From: |
Nicola Pero |
Subject: |
Re: gnustep-base code freeze |
Date: |
Sat, 9 Apr 2011 16:23:22 +0200 (CEST) |
> 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
Re: gnustep-base code freeze, David Chisnall, 2011/04/03
- Re: gnustep-base code freeze,
Nicola Pero <=