[Top][All Lists]

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

Re: Install gnustep-base standalone

From: Sheldon Gill
Subject: Re: Install gnustep-base standalone
Date: Thu, 28 Apr 2005 17:17:47 +0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.


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

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

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

Depending on the FHS in place. The right Debian answer would probably be

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,

reply via email to

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