Re: [Gnustep-cvs] Commit Update

[Nicola Pero]

> > Thinking about it, if Adam is preparing a new major release and we are
> > sort of in prerelease status, it's probably not the right moment to put
> > such a major change in. :-)
> > 
> > So maybe we should keep the option in a ./configure flag so we can develop
> > and play with it, but it will be disabled by default for now (that
> > includes omitting -fobjc-exceptions for now too).
> > 
> > After the release, we can change the default settings to turn it on by
> > default.
> > 
> > Makes sense ?
> > 
> 
> I think there are very different ways people use -base cvs.  I, for one, 
> do not recompile everything if I update -make/-base unless I know I have 
> to.  Also I use/test code snippets with different (often older) compiler 
> versions without reinstalling everything.

So what's your solution ?  Never using real exceptions ?  At some point we
have to switch, and at that point we'll have to break binary
compatibility.  You can postpone it, but you can't avoid it.  Unless we
don't want real exceptions.

If you want to use multiple compilers, keep multiple GNUstep
installations.  I do that all the time.  /opt/GNUstep for your normal
compiler, /opt/GNUstep-gcc-head for your HEAD GCC from CVS, etc.  To 
switch from one to the other,

. /opt/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
. /opt/GNUstep-gcc-head/System/Library/Makefiles/GNUstep.sh

best thing you put all those in a script together with the shell stuff to
add /opt/gcc/bin to the PATH (or whatever you use to activate the HEAD
compiler) and you're done - run the script and you switch from one
compiler to the other one.


> I believe implying that we are "waiting forever" for a feature that was 
> added to GCC's mainline last week (wrt to the GNU runtime) and isn't 
> even fully implemented yet (wrt @synchronize) is a bit out of 
> perspective.  How many GNUstepers have actually tried this feature yet? 

Who cares, unless you have GCC from CVS you won't use it anyway - no
matter if support is on or off, this change wouldn't affect you unless you
have GCC compiled from CVS sources.

And if you do have it, it's probably because you want to play with those
new nifty unstable features such as @try.  Else you'd grab the latest
stable release.


>   I think we should really wait until at least after the 3.5 (or 
> whatever it's called) release of GCC and then give us (and users) some 
> time to play with it before considering whether we want to make it the 
> default.

Ok - let's keep it off, I don't think it makes much difference whether we
turn it on before or after the 3.5 release, except we'll get less testing.

I'm a bit worried about testing the @try stuff.  If we wait for mass
testing *after* the 3.5 release we might end up with support for @try
which is in 3.5 release, it's mass deployed everywhere, but it's broken.  
Then we are in trouble.

That's my only point, but I don't really care, so let's turn it off.