Re: Install gnustep-base standalone

[Sheldon Gill]

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

I'm glad you like that. Response has varied. I think the approval rating 
will go up, though, once people have played with it a bit. Certainly I 
expect the packagers to be in favour.

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

Cool. I wasn't looking for a flame war. There are reasons behind 
heirarchies and, besides which, I've no interest in championing any one 
layout ahead of another.

Well, unless I was designing a new OS or distribution ;)

So don't worry. Speak your mind clearly and freely. It's why I asked...

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

Yes. I agree with you. I posted a way to achieve much of this a long 
while ago. You might want to trawl the archives.

I have a way around this which works quite nicely in the run-time 
environment. It is, though, a work in progress and there are more 
changes to come in time.

The first fix was to eliminate the need to source GNUstep.sh

The second was to add (optional) platform support to NSSearchPath() so 
that it returns the appropriate directories as well. For example, my 
windows machine does this:

Domain: NSAllDomainsMask
  NSApplicationDirectory = <list>
    C:\Local/Applications
    C:\msys/System/Applications
    C:\Program Files

There are *nix examples and more info in the archives. So now, you can 
write tools/applications to use the standard search mechanism and it 
will find platform specific stuff, too.

So...
Tools     => $prefix/bin         NSApplicationDirectory
Daemons   => $prefix/sbin        NSAdminApplicationDirectory
Libraries => $prefix/lib         GSLibrariesDirectory
Resources => $prefix/share       NSLibraryDirectory
Defaults  => /etc                <Step FHS for now>

I'm not sure that putting defaults databases into "/etc" is going to be 
all that helpful. Most sys-admins don't want to hand edit such a file 
and prefer most *nix style configuration files. There is also the 
complexity of some configuration file systems which don't translate well 
to a hand edited defaults database.

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

Yes, it would be very nice to get -make to play better. Some steps are 
in progress but we're already pushing a lot of things in that package.

I have a work-around which is good for now. Have a conventional GNUstep 
installation and write a script to do a FHS specific install for your 
platform.

No, we can't have just *one* script. That'd be too easy. Careful about 
standards. I'll sic the Debian crew on to you ;)

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

Agreed. Luckily, nothing -base is framework.

> Upper/lowercase naming is an issue. It should not be
>   /usr/share/gstep-base/TimeZones/
> but
>   /usr/share/gstep-base-1/timezones/

Depending on the FHS in place. The right Debian answer would probably be
/usr/share/nstimezones

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

Agreed, although on *nix it means SO_NAME discipline and symlinks. On 
windows its a whole other matter. DLL hell has reined for years and they 
*still* haven't bothered to get library versioning support into the OS. 
Even though every library they've shipped for umpteen years has a 
version resource you could check against!

> 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 know that. I responded similarly because it's rigid enforcement got in 
the way of shared library control.

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

Then we're nearly there. I suspect there will need to be some debate 
over the details of the FHS scheme.

My whole goal with the path changes was to make things more agnostic at 
the software level so packagers can argue and do whatever they want on 
different platforms without it driving everybody else crazy.

The key thing is the resource location algorithm. The primary search 
mechanism is there. The next step which isn't so hard is library 
resources for base.

GUI is a whole other thing.

Flexibility in the bundling scheme is an issue, too.

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

Well, performance metrics and tests are always interesting to see. The 
next time you check perhaps you could be somewhat disciplined in the 
approach and document it?

Especially interesting would be data and test cases which are run on 
multiple platforms. I'd like to see lF v base v Foundation on MacOS, for 
example.

{ASIDE: If you, dear reader, have a benchmark test please contribute}

I'd certainly help to address any short-comings.

> Probably easy to solve, but might need some KCacheGrinding.

It's a pretty good tool. For many of the issues initially I suspect we 
can optimise well through source review. Some things are definitely not 
too hard to solve. There are a number of known inefficiencies.

> b) Soname compatibility. I have the _impression_ that GNUstep doesn't  care
>    about that. We need absolutely _strict_ soname compatibility.

Agreed. It's not that GNUstep doesn't care about that. Its more that 
soname discipline hasn't been what it could have been. Given that 
GNUstep's primary (and for a long while almost exclusive) audience was 
developers it wasn't that much of an issue.

Greater circulation and general use is going to change that.

> c) It must not be necessary that any other daemons run for gstep-base  
> to work.

It isn't. Tools can run quite happily without gdomap or gdnc.

That makes it possible to have a separate installation package for them.

>    If DO is not used, do not require the startup of the DO  nameservice. 

It isn't a requirement now.

Just as a note, I'd personally prefer if DO and a few GS extensions were 
moved sideways from base. In my head there is:
base => Foundation, as up to date as possible
baseadd  => Foundation assistance/additions used by base
basemore => Nice to have or supplementary material

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

I agree with you on this. There is another thread I started recently 
with proposals to change/update the coding conventions. Please chime in 
with your views and recommendations.

The debate about this particular code fragment was about BOOL generally 
and has a wider scope. That leads to questions of engineering which I'm 
happy to take up in a different thread....

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

I've been looking in at the porting effort from time to time.

I did try to get OGo to build on base but the whole building scheme was 
a lot more involved than I thought it should be. It was complicated by 
what I found to be a lack of documentation.

I'm at something of a loss to know with any detail *why* OGo doesn't run 
with base at the moment. An detailed issue list would be invaluable.

I'm pretty sure it could be resolved quite quickly with a little 
dedicated effort. Those that know base getting together with those that 
know OGo is really all that it'd take.

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

Tell me about it ;)

I'm a bit different in that I've been sysadmin for *nix boxen but also 
done plenty of *doze. Mac has been a personal thing.

Don't worry. No offense taken. Speak up.


Mach spass,
Sheldon