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 16:11:05 -0800 (PST)

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

> IMHO cross platform does not mean that it runs on linux and frebsd.
Why not? Platform is a combination of a number of factors, including CPU 
architecture, Operating System, etc. GNUstep works on *MANY* CPU archs and 
*MANY* *NIX-based OS'es. How do you see this as 'not cross-platform'?
> 
> 
> Mondragon, Ian <ian.mondragon@bankofamerica.com> wrote:
> 
> > i'm sorry, but i don't think this is exactly true.  what will GNUstep 
> > gain?
> > how many people will *really* run GNUstep apps on a windows box?
> 
> I will. If GNUstep could compile on MacOSX and Windoze, it would be my 
> primary development environment. Hands down.
> 
> >  while the GNUstep community seems to have grown somewhat in the past 
> > several years, it's still been fairly slow growth and there are a lot 
> > of people in the linux/bsd communities that have never heard of/paid 
> > attention to GNUstep... and that doesn't hold much promise for the 
> > windows community at large.
> 
> Part of this is because GNUstep does not have a stable or easy 
> development process. Why should I use this once-recommended-by-a-friend 
> app environment if it is a) not complete b) not up-to-date or c) hard 
> to keep as up to date as it is?
> 
> 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.
> 
> With GNUstep on the next runtime, changing some vars and 'make' will 
> give me binaries for GNUstep or MacOSX. *That* will give GNUstep some 
> major momentum, and it will be adopted by many more people on MacOSX 
> who develop (because it is so simple to add to the existing system, if 
> it were that simple), and many linux/bsd people because they are 
> opening a door to MacOSX apps!
> 
> Another thing that would do wonders for GNUstep is to make it 
> embed-able within an app bundle (I'm thinking for MacOSX here, it would 
> get weird if you're trying to develop w/ an embedded GNUstep).
> 
> If this happened, then GNUstep for winblows would be more like 
> GNU-MacOSX for windows. Then there would be a *real* way to write a 
> program for MacOSX *and* for windoze *and* for linux/bsd.
> 
> > 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) and there are no GNUstep apps that are worth 
> compiling on MacOSX, unless you are looking for an app that behaves 
> *exactly* like the one on your linux box (with GNUstep), in which case 
> you're probably not liking MacOSX to begin with.
> 
> 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...
> 
> More work into porting GNUstep to the next runtime (which I would be 
> happy to help with) and more work into making GNUstep more solid would 
> be what makes GNUstep the best it can be.
> 
> 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!
> 
> 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.
> 
> Part of this is the choice of libs, and the idea of prerequisites to 
> begin with.
> 
> Many libs... let me rephrase. ALL of the graphics libraries that 
> GNustep depends either have NO configure-based build process, or use a 
> process that vaguely looks like it. (libtiff, libjpeg, and libpng). It 
> would make much diff in porting GNUstep to any non-linux/bsd platform 
> to help the maintainers move to a better build system. the packages are 
> quite small, and little work would be needed, and I can't do it myself. 
> This would help the whole GNUstep project, since a simple configure 
> line and make;make install would be required to build gnustep's 
> dependancies.
> 
> Using ffcall for GNUstep's ffi implementation is IMHO bad. AFAIK, 
> ffcall is quite old and, while functional, a pain in the rear. libffi 
> from gcc works just as well, it much smaller, and is much more 
> portable! The way that the HOWTO is written, it seems like one must 
> have ffcall, it is very easy to overlook the libffi package listed as 
> "OPTIONAL". libffi is compiled and installed in almost every post 3.0 
> gcc, why not make *THAT* the recommended package, and make ffcall the 
> "OPTIONAL" one?
> 
> Also, the graphics libraries are vaguely hinted at until configure 
> fails with libtiff, then it doesn't stop for jpeg and png is a single 
> line of "... no" That's not too helpful, especially if I'm wanting a 
> fully working GNUstep installation. Perhaps make the warnings bigger 
> for the latter two, and adding libpng to the HOWTO?
> 
> Also, it would be quite helpful to many if the (thankfully few) prereqs 
> were built and installed within the GNUstep directory structure if 
> they're not found on the system. Libffi and the graphics libs and a 
> recent libobjc are all small packages and can easily be put in a 
> contrib (and I'm not talking about the dev-libs or dev-apps 
> directories) directory. I would be happy to keep it up-to-date, if it 
> does get added.
> 
> I do not know of any recent vaguely *nix-like systems that do not have 
> SSL or XML2 installed, but again this would not be hard to put into the 
> contrib dir. Make it an optional download, simple untar it into place, 
> then ./configure and all is well.
> 
> 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.
> 
> Sorry if this has been a gripe list, I am not trying to just complain.
> 
> JP
> 
> 
> 
> --
> ". . . Through the cold and darkness
> we will look back on this day
> and fall into oblivion.
> Through a brilliance beyond twilight
> we will rise again,
> ready to face the dangers that befall on us . . ."
> 
> 





reply via email to

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