[Top][All Lists]

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

Re: Install gnustep-base standalone

From: Helge Hess
Subject: Re: Install gnustep-base standalone
Date: Wed, 27 Apr 2005 23:07:04 +0200

On 27. Apr 2005, at 03:24 Uhr, Sheldon Gill wrote:
Personally I would prefer that gnustep-base evolves into a state so that it can be used for non-GNUstep development (eg no GNUstep.sh, proper integration into Unix/Windows).
Well, now that the pathutilities patch is in the need to source GNUstep.sh at startup has gone so I guess its getting closer to what you want.


Prior answering the reply below: PLEASE, I don't want to start a FHS vs GNUstep filesystem discussion. IMHO both are necessary and must be supported. The GNUstep hierarchy is much better for AppKit level stuff, the FHS for regular system utilities.

I am curious, though, to know what you mean by "proper integration" into Unix and what are the key issues which result in -base not being "properly integrated".

Mostly the use of FHS pathes for resource, configuration and tool storage. This bites with GNUstep as a high level environment but is important for daemons and system level tools.

More exactly:
Tools     => $prefix/bin
Daemons   => $prefix/sbin
Libraries => $prefix/lib
Resources => $prefix/share
Defaults  => /etc

OGo currently has dirty post-install hacks in all makefiles to make this possible, eg you can call

  make debug=yes FHS_INSTALL_ROOT=/usr/local install

It would be great if gnustep-make would support an "FHS install mode" natively and if gstep-base would support lookup in FHS locations (eg / usr/share/gstep-base-1.10/timezones for timezones). In libFoundation we implement the latter by first checking GNUstep locations if GNUSTEP_ env vars are set and otherwise fall back to /usr/local and / usr. A configurable location should be added to the latter.

And of course such a setup should not use frameworks for gstep-base related things since they are completely unnatural to Unix.

Upper/lowercase naming is an issue. It should not be

And versioning is a _very_ important thing. It MUST be possible to have all different released versions of the same library installed.

Note: all this is out of real life feedback. For first version of OGo we got a LOT of negative feedback that the OGo (GNUstep) environment is 'weird' and 'unnatural'. Which is really unfortunate since one of the major advantages of ObjC is that we can have tools/libs which act/ feel exactly like regular ANSI-C ones.

I definitely would like to drop lF once gstep-base is a suitable replacement.
Can you provide the criteria under which -base would be evaluated as suitable?

I think the only real 'feature' missing is the FHS integration.

Besides that I have four less 'exact' things in mind which make me feel a bit unsure: a) Speed. It should not be significantly slower than lF. In theory it should not (in the contrary), but last time I checked it was nevertheless. Probably
   easy to solve, but might need some KCacheGrinding.
b) Soname compatibility. I have the _impression_ that GNUstep doesn't care
   about that. We need absolutely _strict_ soname compatibility.
c) It must not be necessary that any other daemons run for gstep-base to work. If DO is not used, do not require the startup of the DO nameservice. If I just want to call something like "xmlrpc_call" I do not want gstep-base to
   spend initializing a full OpenStep environment ...
d) Too idealistic coding conventions. I prefer not to have code which does "if ([obj doesIt] == YES)". IMHO there should be an agreement that such is
   changed to just "if ([obj doesIt])".

BTW: currently OGo does not run with gstep-base. But I'm pretty sure that this is a minor issue which could be resolved quickly.


PS: do not take any of the comments as an offense. Unix server apps and GUI desktops are very different in nature. Our 'users' are Unix sysadmins which have a very special idea about the world ;-)

reply via email to

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