Re: New release of the gnustep-base library please test trunk

[David Chisnall]

On 12 Jul 2013, at 08:16, Richard Frith-Macdonald <address@hidden> wrote:

> 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.

Sounds good.  I'm currently in the process of updating all of the GNUstep 
FreeBSD ports, and defaulting to clang 3.3 and libobjc 1.7.  Once the package 
building infrastructure is back up, FreeBSD should be building package sets 
every two weeks, so it doesn't matter too much to me when the release happens, 
but it would be nice to have a -base release where it's safe to use small 
objects and NSNotificationCenter.

> 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

I think that's a good idea.  It should, in theory, support everything that GCC 
libobjc supports, but it also supports a lot of other stuff and testing for 
each of those separately is a bit of a pain.  

> 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.

We've had a similar problem in FreeBSD.  We need to support building with gcc 
4.2.1 and clang whatever-the-latest-that-we've-imported-is, and also want to be 
able to support external toolchains (e.g. 
gcc-hacked-up-by-MIPS-vendor-of-the-day).  Our solution to this is to have a 
set of toolchain description files (makefiles that are included by our build 
system) and fairly abstract things that are used.  Implementing support for a 
new compiler is (in theory) just a matter of implementing this file.

Note that we can speed up the configure step a lot if we detect clang as the 
compiler by turning all of the header checks into __has_include() things.

> 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).

I'd agree.  There are basically two sorts of platforms that we care about for 
clang:

- Those that package it in a timely fashion, so have the latest available 
easily.
- Those that don't package it at all, so users need to get it from upstream.

There's very little advantage in supporting older versions of clang.  In the 
case of gcc, there were a couple of good reasons for supporting older ones:

- gcc had a habit of dropping platforms that we cared about from newer releases.
- Long-term support distributions (e.g. RHEL) picked a GCC version and then 
kept it for 5 years.

So far, the only vaguely mainstream platform to be dropped from Clang/LLVM is 
Itanium, and the Itanium back end was so buggy that no one in their right mind 
should have used it.  I don't know if the latter applies yet to any platforms, 
but if it does then they're likely shipping clang 2.9 or similar, and it's too 
much effort to support.

David

-- Sent from my PDP-11