discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Is GNUstep really cross platform? (was: FW: GNUstep on MS Windows (O


From: Alex Perez
Subject: Re: Is GNUstep really cross platform? (was: FW: GNUstep on MS Windows (Oh boy...i've done it now!))
Date: Thu, 4 Dec 2003 23:12:19 -0800 (PST)

You don't need to compile gnustep-base on OS X. This is pointless, and 
needlessly redundant. GNUstep was not designed to compile under OS X for 
the reasons listed above. The most you would/should ever need to get a 
GNUstep app to compile under OS X is GSCompat. The primary issue for why 
GNUstep doesn't compile properly under OS X is due to a moron at apple/FSF 
who *INTENTIONALLY* broke the ability of the GNU Objective-C runtime to 
function under OS X. This is currently in the process of being fixed, and 
has nothing to do with GNUstep in any way (other than us advocating that 
it be fixed, more than the OS X folks have done for the issue to date).

On Thu, 4 Dec 2003, John Davidorff Pell wrote:

> We seem to have VERY diff sets of information.
> 
> I tried to compile GNUstep on MacOSX from cvs HEAD only a few weeks 
> ago. For my full procedure, go to: 
> http://gaelicwizard.kicks-ass.net/~pell/content.php?content=gnustep
> 
> If you ignore the opinions (which from your email seems to be unlikely, 
> no offense), you'll find that there is a whole lot that I had to do to 
> get a GNUstep-base to compile in a usable way, including compiling 
> GNU's objc runtime. GNUSTEP BASE WILL NOT WORK ON APPLE's RUNTIME! The 
> "additions" do compile, but then I don't have a working GNUstep-base, 
> and no DO.
> 
> FYI, I have never used, nor know anyone who uses, ONLY GNUstep-base. 
> I'm talking about GNUstep as in ALL OG GNUStep, including GNUstep-gui.
> 
> 
> On Dec 4, 2003, at 1:55 PM, Philip Mötteli wrote:
> 
> > Am 04.12.2003 um 21:57 schrieb John Davidorff Pell:
> >> I think that the biggest thing that GNUstep could do is make it run 
> >> on the next runtime, or even make it compile and link its own gnu 
> >> runtime on darwin. With this I, and many like me, would happily 
> >> develop for *both* GNUstep and MacOSX, without any need to *hope* 
> >> that GNUstep will compile my sources.
> >
> > I'm sorry, but the problem, you're mentionning is not as big as you 
> > think. It's right, the runtimes are not compatibel, but
> >
> > 1. You shouldn't need to go down to the runtime anyway. This should 
> > really happen very, very rarely.
> > 2. GS already offers a lot of compatibility functions. Just use those 
> > functions and they will automagically compile on both platforms.
> 
> You don't need to go down to the runtime, GNUstep does all that for 
> you. but GNUstep does NOT work between runtimes!
> 
> >
> >>> as long as you stick to the Foundation/AppKit, most things will 
> >>> compile on Mac OS X
> >>
> >> At the moment, GNUstep won't even try to compile on MacOSX (that's 
> >> only a slight exaggeration)
> >
> > That's a long time ago, that GS didn't compile on MOSX. We have moved 
> > forward a long time ago. We already ported GDL2 (EOF) and in a few 
> > days I gonna probably release a binary installer package for GSWeb 
> > (WebObjects).
> > Just make a check-out from CVS of GS and you will even find an Xcode 
> > project file.
> > It's even better: For the GS core, we only use the difference from GS 
> > compared to Apple's Foundation framework.
> 
> You use "additions", I understand that. but that is USELESS if I want 
> to compile GNUstep-gui. Care to port GNUstep-gui to work on 
> apple-apple-gnu?
> 
> >> I've noticed over the time that I've been following GNUstep that some 
> >> effort is put into making the latest updates from apple become part 
> >> of GNUstep, without much consideration for making the old stuff work 
> >> *well*, or for making the *new* stuff work well. Actually, its more 
> >> like there is very little effort being put into GNUstep to begin 
> >> with, but that's the whole subject of this thread...
> >
> > Exactly. But as soon, as the MOSX people will be up to date, how 
> > usable GS already is on MOSX, they will hopefully show the respect it 
> > deserves.
> > You seem to be a good example of how misinformed the MOSX community 
> > still is. Though I made an announcement very recently, concerning a 
> > downloadable binary installer package containing GDL2 and GS for MOSX.
> 
> So you'd rather have many mostly-working functions, than any working 
> ones? I'm exaggerating, but please understand my point.
> 
> >
> >
> >> By solid I do NOT mean stable. GNUstep is very stable, but it is not 
> >> solid. This is a problem with many open source projects, gnome and 
> >> kde included. All over the place new features are added that depend 
> >> on so-and-so 3rd party library, but then no two compilations are 
> >> compatible and all kinds of things require recompilation of the 
> >> entire lib suite!
> >
> > In order to compile the core of GS you don't need to install anything 
> > at all on your Panther box. No lib, nothing.
> 
> Wrong, see above.
> 
> >
> >> With GNUstep it is an even bigger issue, since we have the concept of 
> >> DO. This means that you really do need to have most boxes be 
> >> compatible, not to mention all builds on the same computer 
> >> compatible.
> >
> > GSs DO and Apple's DO are not compatible, because Apple doesn't open 
> > its specifications. But you still might use something like XMLRPC.
> 
> That's not what I'm talking about. I'm talking about DO completely 
> under GNUstep, using only the apple runtime.
> 
> >
> >> I've not actually used GNustep in a short while, since my primary box 
> >> is MacOSX, maybe I'm the one who's out of date.
> >
> > You're definitely living somewhere in the tertiaer or before!
> 
> Not really.
> 
> 
> > Re
> > Phil
> 
> Thank you for your reply, but perhaps you should check your information 
> before you tell me to check mine.
> 
> JP
> 
> --
> if (message.signature==FUNNY) steal(message.signature); else 
> message=message->next;
> 
> 
> 





reply via email to

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