[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New release of the gnustep-base library � please test trunk
From: |
Richard Frith-Macdonald |
Subject: |
New release of the gnustep-base library … please test trunk |
Date: |
Fri, 12 Jul 2013 08:16:59 +0100 |
I'd like to make a new release of gnustep-base in the near future.
We have a big patch needing merging in which will introduce binary incompatible
changes, so this would probably be the last significant release in the 1.24
series, and would be 1.24.5
The 1.24.5 release will provide quite a large number of minor bugfixes,
particularly on 64 bit platforms. This version includes checking of
printf-style format string arguments when building using clang, and should be
free of any faults detected by the clang static anlyser.
I'd like it to be a version we can confidently advise people to use, so please
could people download and test base from svn trunk as much as possible during
the next few days.
After this release, I'd like to go on to work on 1.25.0 with a focus more on
supporting ObjC2 development since I now believe clang and the runtime are
becoming / may have become sufficiently stable for us to be be able to produce
a user-friendly install process for an ObjC2 development environment.
I think this will require some restructuring between gnustep-make and
gnustep-base. The reason for this is mostly that, while clang and David's
objc2 runtime were both designed as drop-in replacements for gcc and the gnu
runtime, the reality is that they aren't (certainly not when it comes to ObjC2).
1. I think, we need more library-combo's. Specifically we should have a new
runtime designation for David's objc2 runtime, rather than trying to treat it
as a variation of the gnu runtime.
This would hugely reduce/simplify the required autoconf tests
2. I think we need library-combo specific compiler settings in gnustep-make.
The original gnustrep-make design esentially assumed everything would be built
using gcc. However you can't get full ObjC2 support with gcc, and clang uses
somewhat different flags, so we need different compiler flags and libraries to
be used when building for ObjC2 than wehn building ObjC1 code.
3. While giving clang first class support for libobjc2, I think we need to drop
support for older versions (and possibly when compiling for ObjC1) to
concentrate on targetting a specific minimum version (possibly 3.3 ... not
sure what's actually needed).
- New release of the gnustep-base library … please test trunk,
Richard Frith-Macdonald <=