Re: [Gnustep-cvs] Commit Update

[Nicola Pero]

> > +   * configure.ac: Detect native exception handler support in the
> > +   compiler, and set HAS_OBJC_EXCEPTIONS to yes if it's there.
> > +   * configure: Regenerated.
> > +   * config.make.in: New variable HAS_OBJC_EXCEPTIONS.
> > +   * common.make: If HAS_OBJC_EXCEPTIONS is set, add
> > +   -fobjc-exceptions to the ObjC flags.
> > +   
> 
> Hello Nicola,
> 
> I'm not sure we want to do this in this way.  Mixing -fobjc-exceptions 
> code with old style exception code will most likely cause serious 
> problems.  (AFAICT, unlike Apple, we actually use GCC's native exception 
> handling features already where as Apple still does setjmp/longjmp for 
> the new constructs for backward compatibility.)  An update in gcc 
> shouldn't require you to recompile everything.  I think we should only 
> activate the feature if explicitly requested by the user as a 
> ./configure option.
> 
> Or did I miss something?

NB: unless you're actually using @try/@catch/etc, adding -fobjc-exceptions
on the command line does no harm so this special change to gnustep-make
has no visible change for the users who are not interested in using @try
but want to stick with NS_DURING.

But, this change was only the first step in the plan ...

The next bit will be to actually update gnustep-base so that when
HAS_OBJC_EXCEPTIONS is set, NS_DURING will be a wrapper around @try, and
similar stuff, so that all exceptions will be native, and there will be no
risk of mixing -fobjc-exceptions with old style exception code: if you
compile/install gnustep-base with a compiler which supports
-fobjc-exceptions, you get real exception handling, if you compile/install
gunstep-base with a compiler which does not support -fobjc-exceptions, you
get traditional "emulated" exception handling.

But yes, there are backwards compatibility issues - if we start converting
NS_DURING into a wrapper around @try, when you update your
gcc/gnustep-base you will likely have to rebuild everything which uses
NS_DURING and similar, which is everything.

But then you get *real* ObjC exception handling, which not even Apple
gives you!  :-)

And if you don't recompile/reinstall your gnustep-base, you don't have to
recompile anything even if you update your gcc and your gnustep-make.

I understand the problem of backwards compatibility - we probably need to
warn users and make sure distributions know about the incompatibility and 
tag their packages and set up package dependencies in such a way as to 
avoid conflicts due to "old" packages mixing with "new" ones.

But sooner or later we'll have to do the jump to real exception handling
anyway if we want to take advantage of it.  I don't see a point in
delaying it forever.  It's a lot more exciting to do it before Apple does
it btw :-)

But I agree it should be planned, and we need to manage the release 
versions etc.

The current change to gnustep-make didn't affect anything yet though.  It
just detects objc exception handling in the compiler, and adds
-fobjc-exceptions to the command line, which has no effect because we're
never using @try.