gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] GNUstep Testfarm Results


From: Gregory John Casamento
Subject: Re: [Gnustep-cvs] GNUstep Testfarm Results
Date: Mon, 14 Aug 2006 06:58:19 -0700 (PDT)

Fred,

> I would prefer to turn the tone a bit down again. What you wrote may be

> regarded as very negative by some.

My apologies, if it seemed negative, it wasn't meant that way.   I tend to
be direct, so sometimes it comes off that way via email. :)

> I don't know about any specific GNUstep feature, we did not implement in
> the last year because we actively decided that support for gcc 2.95 was
> more important. Until such a case turns up, why not go along with what
> Adam and Riccardo suggested: We don't offically support gcc 2.95, but we
> try to keep things running in that environment. If we know about issues
> and know how to fix them we should do so.

My original suggestion was to simply consider it "non-release critical" so
that, if something failed to compile in GNUstep under GCC 2.95.x we would
would not hold up a release for it.

I can see no problem with this, so long as it is a GNUstep-wide policy.  If
we start making exceptions, as Riccardo suggested for the "core" pieces, it
becomes confusing.  If you go back to one of his previous posts, you'll see
that he suggested *officially* supporting gcc 2.95.x for "core" parts of GS.
Official support, to me, implies that we will hold up a release for it.

> I remember that from time to time we break compilation for older
> compilers by declaring new variable in the middle of the code. Now I
> don't see any problem in only declaring variables at the beginning of a
> block. Actually we all try to do this, although it old fashioned by now.

We all do this because we must support C89, which is what gcc 2.95.x
conforms to.

> Talking about ancient architecture. Isn't GNustep all about that? We
> started off as a step in replacement for NextStep, we just should not
> talk too negative about old things :-)

Yes, GNUstep started off as a replacement for NeXTSTEP/OpenStep, but it
has grown since then.  We have to drop support at some point for things.
GCC 2.95.x is quite old, and buggy.  I'm simply saying that I think we
should make it non-release critical for all of GNUstep.

That being said, as I also said prior, we shouldn't go out of our way
to break things.   But, by the same token, we should also not go out
of our way to make things work, when and if something does fail.

P.S. I am not trying to sound negative, just giving my opinion on the
matter. :)

Later, GJC
--
Gregory John Casamento


----- Original Message ----
From: Fred Kiefer <address@hidden>
To: Gregory John Casamento <address@hidden>
Cc: Developer GNUstep <address@hidden>
Sent: Monday, August 14, 2006 9:04:54 AM
Subject: Re: [Gnustep-cvs] GNUstep Testfarm Results

Hi Greg,

I would prefer to turn the tone a bit down again. What you wrote may be
regarded as very negative by some.

I don't know about any specific GNUstep feature, we did not implement in
the last year because we actively decided that support for gcc 2.95 was
more important. Until such a case turns up, why not go along with what
Adam and Riccardo suggested: We don't offically support gcc 2.95, but we
try to keep things running in that environment. If we know about issues
and know how to fix them we should do so.
I remember that from time to time we break compilation for older
compilers by declaring new variable in the middle of the code. Now I
don't see any problem in only declaring variables at the beginning of a
block. Actually we all try to do this, although it old fashioned by now.

Talking about ancient architecture. Isn't GNustep all about that? We
started off as a step in replacement for NextStep, we just should not
talk too negative about old things :-)

Cheers
Fred


Gregory John Casamento schrieb:
> Riccardo,
>
>> In any case, and I know I think differently than several people here, I
>> would prefer to retain gcc 2.95 compatibility at least for the core
>> libraries and, if possible, for all "GNUstep supplied" applications. Or,
>> at least, the fundamental ones: gorm, project center, system preferences
>> and if possible gworkspace.
>
> So basically all of GNUstep, is what you're saying.   This seems to run
> counter to what we're discussing.   The problem is that there are too
> many limitations we must impose on the code in order to maintain that
> compatibility, as I described in my previous posting.
>
>> Of course this does not apply top linux/x86 which almost everyone uses.
>> It is just for the 1% of the remaining 1%. But it is one of the reasons
>> why I always liked gnustep.
>
> GNUstep needs to move forward, we can't be held back by the 0.01% of people
> who might be using it on an ancient architecture.
>
> While we should strive to have a wide variety of machines, we shouldn't
> go out of our way to make it work on machines which are no longer in common
> use.
>  
> --
> Gregory John Casamento
>
>
> ----- Original Message ----
> From: address@hidden
> To: address@hidden
> Cc: Fred Kiefer <address@hidden>; Developer GNUstep <address@hidden>
> Sent: Sunday, August 13, 2006 4:26:26 AM
> Subject: Re: [Gnustep-cvs] GNUstep Testfarm Results
>
> Hello,
>
> On Friday, August 11, 2006, at 12:02 AM, Adam Fedor wrote:
>
>> I narrowed it down to one method, but that doesn't really help much. On
>> the solaris, I'm still using the 2.95 compiler, mostly to check for
>> backward compatibility. Perhaps I should just upgrade and start
>> deprecating support for gcc 2.95?
>
> I used to regularly test on gcc 2.95 the core libraries on various
> platforms. It is just that lately I was too busy with other important
> life tasks.
>
> In any case, and I know I think differently than several people here, I
> would prefer to retain gcc 2.95 compatibility at least for the core
> libraries and, if possible, for all "GNUstep supplied" applications. Or,
> at least, the fundamental ones: gorm, project center, system preferences
> and if possible gworkspace.
>
> I do not want to enter the eternal gcc 2.9 versus gcc3.x or gcc 4.x
> discussion. Mountains of ascii bytes have been spilled about that. I
> know 2.95 has many problems. Even Linus Torvalds spoke about the issue.
> I just want to remember that newer gcc's are not a good option on more
> than one platform (mostly because of C++, not because of obj-c or C
> itself) and that gcc guys aren't that happy anymore to fix problems on
> arcane platforms as they did on 2.9 series. Furthermore not everybody
> may want to upgrade gcc (possibly because the box is managed by others
> and 2.95 is the easiest choice) and having more than one compiler
> installed (of which some are incomplete, like lacking C++ or in any case
> have big api differences like 2.95 and 3.x have) is cumbersome.
>
> Of course this does not apply top linux/x86 which almost everyone uses.
> It is just for the 1% of the remaining 1%. But it is one of the reasons
> why I always liked gnustep.
>
> Regarding solaris and the bug in discussion, I have gcc 3.x installed so
> we can check this out too. On Sparc but OpenBSD I have 2.95.
>
> I will resume testing on more arcane platforms ASAP.
>
> Have fun,
>    Riccardo
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev


reply via email to

[Prev in Thread] Current Thread [Next in Thread]