Re: questions about GNUstep

[Richard Frith-Macdonald]

On Wednesday, November 21, 2001, at 08:46 PM, e.sammer wrote:

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

The makefiles package is really cool for development of any software ...
people use it for non-gnustep stuff quite a bit.  So there are many
people who might want to use it without using any of the GNUstep 
libraries.

The base library is used for *lots* of non-gui production code ... for
instance, our company codebase is almost entirely built using 
gnustep-base,
but doesn't touch gnustep-gui.

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

Well ... it's pretty simple to download and install the rpms you want
if you are using them, and of course if you use debs there is really no
issue since the package management system will select and download
evertything for you.

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

Basically, the GNUstep makefiles make setting up projects really, really
simple (which is good reason to use them rather than handcrafting
makefiles even for non-GNUstep code), and the whole autotools stuff is
irrelevant for GNUstap apps since a large part of the point of
the OpenStep API is to provide platform independance .... you code to
the OpenStep API and all platform dependencies are hidden from you by
GNUstep.  Of course, living in an imperfect world there are cases where
you want to write non-GNUstep code which uses platform specific APIs
and in these circumstances you can drop back to using autotools to handle
those dependencies.

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

Can't see anything to be gained here ... presumably a matter of personal
taste ... there's nothing to stop you changing this to the setup you like
using environment variables to change the location of the directory.

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

NFS ... fileserver containing binaries used by different machines.

Actually, there is an option 'FLATTENED' to remove the hierarcy ... but
I don't think anyone actually uses it and for all I know it may have been
broken in recent changes.

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

I think some sort of CORBA based bridge between the two systems may be
possible ... but I've never had the time to really look into it.

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

They are...
I'm not sure what you 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.

1. I don't think the wmaker people want to use objc (in the past ... 
pre-3.0
gcc has had intermittently poor objc support) for portability.

2. I'm not sure how much useful integration (beyond that already in 
place of
course) there is to be had between the window manager and apps.