questions about GNUstep

[e.sammer]

I've spent some time going over the GNUstep code, makefiles, and other
support stuff in an effort to get to know the code better. I've been
paying special attention to a few different things like NSConnection
implementation and things like that. During my travels through the code
and makefiles, I've come up with a number of questions that I thought I
might post to all...

1. Installation of Base, GUI, and Makefiles

My first question is why are the Makefiles, GUI, and Foundation
distributed separately? I know that during development things must be
kept separate to facilitate clean development and organization, all of
which I firmly believe in, but I couldn't figure out why someone would
install only one or two of these packages. I know that Foundation and
AppKit are dependant on the makefiles, but I would think that given the
proper organization within the source distro, proper building could be
achieved. I am the kind of person who likes to build everything possible
from source (call it a bad / good habit), but for those who choose to
use packaging tools like rpm or the deb tools, I would think that this
simply adds another layer of dependencies to fight with (which seems to
be a _major_ problem with many of the package systems). It would seem
that these three things would be better distributed as a whole, rather
than in pieces. Of course, things like download size, ease of updating,
and other such issues do come into play, but it would still would be
possible to release patches or updates to individual parts, as required.

2. The Makefiles package

I was curious as to why the NeXT / Apple makefiles were kept the same.
What I mean is with many projects using the GNU "autotools" (autoconf,
automake, aclocal, m4, etc.) it would seems a viable option for the
GNUstep build system. I am also aware that this is probably done to
maintain makefile compatibility with NeXT, WO, and (older) MOSX Server
projects, but providing a simple shell or perl conversion script might
also do the trick. In theory, this is what is being done for nibs, so it
wouldn't seem _too_ nutty to convert the makefiles as well. The main
reason for this question is cleanliness of the build system. Not that
the makefiles don't work, but having a set of m4 macros for the GNU
autotools could greatly improve overall usability, as well as centralize
configuration of a source tree. This would also allow easier integration
into different Linux / Unix IDEs as many of them use these tools in the
background. The autotools provide a standardized way of system arch
detection, header testing, library testing, program existence, compiler
sanity checks, and other flexible options that make them prime for this
kind of development. Also, with many other projects using the
"<appname>-config" style shell scripts to centralize the location of
CFLAGS and linker args (see gtk, glib, imlib, xmms, libxml, etc.) it
seems to be gaining much wider acceptance.

3. The ~/GNUstep directory

The user GNUstep directory also raised a question or two. I was curious
why this directory wasn't preceded by a "." (dot) to blend in with the
rest of the "configuration-type" items in one's home dir? I know that it
contains items that are commonly in the user's home directory (Library,
etc.) which also made me wonder why these isn't an option to allow these
directories to be created at the ~/ level. I know many users wouldn't
understand (unless they've worked on a NeXT or MOSX(S) machine) what
these directories are all about, but I also think most people who try /
use GNUstep understand (at least) a little about these environments.
Maybe an option would be to create ~/.GNUstep with all of the NeXT-style
directories inside and them sym link them at the ~/ level. This would
seem a nice common ground.

4. Arch Dependant Directories

I have seen a number of projects that make use of architecture dependant
directories (gcc, bin86 utils, GNUstep, ...) which I've always been
curious about. In theory, most things on a Linux / Unix system are arch
dependant at their base level including many headers, libraries, and
most anything compiled. To me, it seems redundant to create arch
directories on the system when the entire system is of that arch. I know
of a few people who cross compile apps, but the base arch (to my
knowledge) is always the same (x86, PPC, MIPS, SPARC, etc.). I'm not
aware of (except for one Sun PCI card and the Apple 7100, I think) a
system other than maybe mainframes running multiple images of Linux that
can natively support completely different hardware archs running at the
same time, in the same environment. I have never actually tried to
compile a PPC binary on a x86 Linux box, but it seems slightly odd to
me. The major thing here is directory cleanliness and whether or not
directory structures like
"$GS_SYSTEM_DIR/Libraries/ix86/linux-gnu/gnu-gnu-gnu" are really
required. Of course, I'm willing to learn.

5. Compatibility Within?

I've posted one or two questions regarding getting NSConnections on GS
to speak to MOSX(S) or NeXT. It seems that this is not possible (and
never will be), which is sad, really, as NSConnection is very elegant
for developers. I know that this is an implementation issue and it would
not be worthwhile to reverse engineer the Apple implementation of
NSConnection and all of the other classes that go along with it (not to
mention that none of us want to get sued). I can understand that. What I
am curious about is if anyone else has a desire for this kind of
functionality. It seems that this doesn't bother anyone which surprises
me. The answers I have received are things like "use XML-RPC or Soap"
which, although helpful and possible, I'm sure I'm not the only one who
would like to use the NSConnection methods instead. Maybe what we need
is a formal project that is a "supported" or "sponsored" framework for
MOSX(S) / NeXT to promote compatibility, use, and acceptance of GNUstep.

6. Dev Environment

Project Center and Gorm have made leaps and bounds and are great apps.
My question is regarding why they aren't part of the actual GNUstep
project. The reason I ask is because NeXT and now MOSX have the hands
down best development environment I have ever used. Don't get me wrong,
I love "vi" for c, c++, perl, shell, and small objc projects, but for
full blown GUI apps, nothing beats Apple's PB/IB combo. I normally do
not like IDEs because they tend to limit the way we work as developers,
but there's something about the way these two apps work together that
makes it almost impossible not to get the job done. That said, they are
not without flaw, but they are a great start (and then some). I would
_love_ to see GNUstep get the same kind of environment and really think
it would bring many, many, many new (or should I say "GNU") faces to the
GNUstep / open source playground. ObjC is not the end-all-be-all
solution to every project, but with tools like this at our disposal, the
projects where it is applicable are a breeze (well, you know what I mean).

7. Integration

One of the best things about some of the newer apps for MOSX is the IPC
functionality between related apps. One of the things that I've always
been curious about is why this isn't taken advantage of at the window
manager level. Of course, WindowMaker, which I understand to be the
officially-unofficial window manager of GNUstep, isn't written in ObjC
which makes such a task difficult, but I imagine with a little
creativity (aka language bindings) this could be possible.

Many of these questions are not meant to cause any (additional) turmoil
in the GNUstep community, but more for the sake of curiosity. I, for
one, would really like to see GNUstep grow into the technical marvel it
is destined to be. I would really like to hear any comments or
corrections to my questions. As a good friend said to me the other day,
"the best thing about open source is the ability to speak and actually
be heard" (I'm paraphrasing here...)

Thanks to all for reading!!!

--
e.sammer
eric@lifeless.net