Re: Install gnustep-base standalone

[Helge Hess]

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.

Great!


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
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
  /usr/share/gstep-base/TimeZones/
but
  /usr/share/gstep-base-1/timezones/

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.

Greets,
  Helge

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