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,
_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev