Re: ANN: One Step to GNUstep - pre-release version 0.9

[Richard Stonehouse]

On Sun, Jun 12, 2011 at 02:44:31PM +0100, David Chisnall wrote:
> On 10 Jun 2011, at 17:40, Richard Stonehouse wrote:
> 
> > I haven't been following the clang/Objc 2 discussion because it's
> > a bit above my head :-)
> > 
> > Are they now stable and mainstream, or still a bit experimental?
> 
> I have been using Clang as my default compiler for C, and Objective-C since 
> about 2009, and for C++ since the middle of last year.  The only problems 
> that I've encountered have been occasional breakage in trunk (as happens with 
> any project), or in some experimental features.  
> 
> The latest release versions of clang and the GNUstep runtime provide feature 
> parity with the iPhone Objective-C stack, but lack GC support.  The current 
> trunk releases provide feature parity with OS X 10.6, including GC support.

Thanks, that's good to know. I see that openSUSE (the distribution I
use) intends to adopt GCC 4.6 as default compiler in the next release
but, currently, it is breaking quite a few of their package builds.
However I don't know whether that is the fault of the compiler or the
packages. I've seen no complaints about clang, but suspect this is
because there is less work being done with it.

> > What sort of developer would you see as having need of clang and
> > Objective C 2?
> 
> 99% of Objective-C developers these days are coming from Mac or iPhone 
> development.  All of the recent tutorials make heavy use of Objective-C 2 and 
> 2.1 features, such as synthesized properties or to add instance variables in 
> a class extension, rather than requiring them to be declared in a header.
> 
> Currently, to the best of my knowledge, these features are supported by the 
> combination of clang and the GNUstep runtime, some requiring the latest 
> release of both (2.9 and 1.4, respectively):
> 
> - Associated references
> - Blocks
> - Non-fragile instance variables
> - The forwarding mechanisms added with OS X 10.5
> - Full protocol and property introspection
> - Type dependent dispatch (protects against various type-related bugs)
> - Unified Objective-C++ exception model, allowing Objective-C++ code to catch 
> C++ and Objective-C exceptions
> - Fully thread-safe +initialize (with Apple-compatible locking semantics)
> - Correct support for C++ objects as ObjC++ object ivars
> - Apple-compatible garbage collection (trunk only, needs testing and not 
> ready for production use yet)

Are you saying these are provided by clang but not by GCC 4.6?

> The following are only available with clang or GCC 4.6:
> 
> - Declared properties
> - Fast enumeration
> 
> In addition, clang provides significantly more expressive error messages, 
> which is a huge benefit for anyone writing code, and a static analyser which 
> can catch a lot of bugs.  The front end is also reusable. For example, 
> Étoilé's SourceCodeKit uses it for syntax highlighting and indexing source 
> files.  This means that the code editor can highlight tokens with exactly the 
> types that the compiler sees (for example, differentiating between macro 
> instantiations and function calls, between typedefs and built-in types, and 
> even between local and global scope variables.  I used this for the syntax 
> highlighting in the ePub edition of the Objective-C book.

OK, from what you and Ivan say it seems clear that there's a need to do
something about Objective C 2.0. I'll pull down the openSUSE packages
of clang and gcc-4.6, and have a go at doing some GNUstep builds, then
think about where to go from there. Either way, presumably, the GNUstep
libobjc2 will be required.
 
> Since GCC decided to switch to GPLv3, there has been no active development on 
> GCC by Apple employees.  As Apple owns the trademark on Objective-C, this 
> makes clang / LLVM the de-facto standard Objective-C compiler.  

The licensing issues are important - we want to avoid lock-in. But
this does not preclude developers using clang if it provides a better
development environment. Dual-sourcing is good, if it is practicable.
My worry is that the features supported by the two compilers may
diverge (or have they done so already)?

> Anyone coming from OS X or iPhone development is going to expect either 
> clang, or a compiler with equivalent functionality to clang.  Giving them an 
> Objective-C environment that is just about at feature party with OS X 10.4 
> does not give the best impression of GNUstep.
>
> > Would this be in place of, or in addition to, the gcc compiler and
> > libobjc?
> 
> Some people may wish to have GCC support as well.  I've recently stopped 
> testing everything with GCC, as the lack of features means that I can no 
> longer build significant portions of my code with it (anything that requires 
> the non-fragile ABI or blocks, and anything that needs to interoperate with 
> code using GC), although I still try to test code that only uses ObjC 1 
> features with GCC 4.2.1 (the last GPLv2 version - the license change means 
> that I will probably never see more recent GCC in the FreeBSD base system - 
> FreeBSD 9 is expected to ship with Clang and GCC, FreeBSD 10 with just 
> Clang).  

What I'm leaning towards, if it turns out to be practicable, is using
GCC 4.6 for the GNUstep library builds but including clang for
developers' use. That is assuming there's no incompatibility between
GCC-compiled GNUstep libraries and clang-compiled applications. But
that's not necessarily my last word!

> Étoilé requires the GNUstep Objective-C runtime for various features, most 
> significantly for LanguageKit, which depends on certain features of the 
> runtime which make it easier to target for languages like Smalltalk.  Various 
> modules require clang, although I think the core ones (EtoileFoundation and 
> friends) will still build with GCC.

-- 
    Richard Stonehouse