Is GNUstep really cross platform? (was: FW: GNUstep on MS Windows (Oh boy...i've done it now!))

[John Davidorff Pell]

IMHO cross platform does not mean that it runs on linux and frebsd.


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 . . ."

smime.p7s
Description: S/MIME cryptographic signature