gnustep-dev
[Top][All Lists]
Advanced

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

Re: libgnustep-base split proposal


From: Richard Frith-Macdonald
Subject: Re: libgnustep-base split proposal
Date: Wed, 22 Feb 2006 07:22:14 +0000


On 19 Feb 2006, at 22:30, Riccardo wrote:

Hey all,


On Sunday, February 19, 2006, at 06:27 AM, Andrew Ruder wrote:

Objective-C is an incredible programming language, but right now the
most crippling factor for its widespread use is the lack of a "standard library." Right now there are two prevalent options to utilizing Obj-C in your program: GNUstep and OS X. Obviously the biggest problem with
OS X is that it is not free.  GNUstep, however, brings along a whole
lot of other problems: crazy GNUstep/ directory structure, daemons,
config files, etc.. etc.. A typical developer not familiar with GNUstep
sees these things and runs the other direction.

this triggers some thoughts in my mind and some desires I have since long. On the other hand it uncover fears. Thus in this email I essentially don't take a position. Although it could be seen as I have one, if some conditions are met.

Personally, the only think I have against this split is complication. I want to retain the current set-up for the typical user install (even more personally I'd desire a back/gui merge so that only two packages would exist: Foundation and AppKit). I also fear it could create inefficiencies int he code and generally I do like every much that ALL gnustep libraries stay in one tree and not spread around.

ON the other side, I must admit that more than once I'd like to use objective-c as a "normal OOP" language, using basic stuff as collections and strings. POC for example, has some of these basic classes. Using gcc obj-c I have nothing. And I don't want all the big base library,daemons, etc. In that case I just need a "library" to install in /usr/lib if I can explain myself. Maybe even be able to making static binaries...

You can do that now with the base library ... simply copy the shared library file into place rather than installing the whole base package. I doubt whether it works as a static library though ... last time I tried (some years ago) the static library failed due to some difference in the order in which things were loaded into the runtime which I failed to track down.

Jeremy Cowgar said that he had problems because the base library creates/uses a user defaults database, and he didn't want it doing that... so I spent a little while making that behavior optional ... and you can pick up the new version from svn.

Setting the config value 'GNUSTEP_USER_DEFAULTS_DIR=:INTERNAL:' will tell it not to use the external defaults database while keeping all the rest of the defaults functionality intact.

There are four ways to set config values ...
1. Set default config values when you run 'configure' prior to building gnustep-base (not recommended normally)
2. Edit the system-wide config file /etc/GNUstep/GNUstep.conf
3. Edit your personal config file .GNUstep.conf
4. Use the GNUstepConfig() function to set it ... also allowing you to prevent the config files (2 and 3) being read.

Thus if I had such a small "standard library" small and lean and even usable with POC (or mimicking some of what POC already has) I could use obj-c much more freely and also untied from GCC.

We could extract some of our extensions to a library, clean up some of the classes to make small and lean objects (not NS* stuff) and then base the NS* stuff on them.

The POC manages a *very* different dialect of ObjC and all the runtime stuff is different ... so core stuff right back to much of NSObject would need changing if you want a library which does not need GCC. The ideal does have a lot of appeal, but I fear it would be far too much work,





reply via email to

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