[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: Thu, 28 Apr 2005 21:27:44 +0200

On 28. Apr 2005, at 11:17 Uhr, Sheldon Gill wrote:
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've also posted some mails on the subject in the past, feel free to trawl yourself ;->

Defaults  => /etc                <Step FHS for now>

I'm not sure that putting defaults databases into "/etc" is going to be all that helpful.

Ah, OK, I wasn't clear enough. Actually this is different for daemons and tools. The former should store their defaults (their configuration) in /etc. The latter of course in the user home.
Daemon configuration should not depend on Unix users.

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.

Thats basically what our fhs.make files do. They just move the files into FHS after installation into the GS tree. Quite hackish, but works.

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

Those are timezone definitions of GNUstep, not of NeXTStep. So it would be gstimezones at least.

LibFoundation uses:
address@hidden:~$ ls /usr/local/share/libFoundation/
CharacterSets  Defaults  TimeZoneInfo

Which isn't perfect due to case issues, but sufficiently good (and approved in Debian ;-)

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.

Well, Windows is supposed to be broken, so its not a big issue for me. Maybe we could install into the GAC ;-)

Flexibility in the bundling scheme is an issue, too.

Yes, bundles are an issue since they are also 'unnatural' to Unix. A feature I would love to see is that bundles don't need to be a directory (directly load a .so module).

Eg in OGo we have bundles for all the web applications. Yet the resources of those bundles (the templates) are already living in share/opengroupware.org-1.0a/templates. So the bundle directories itself are basically empty wrappers with just the code:
address@hidden:~$ ls /usr/local/share/opengroupware.org-1.0a/templates
AddressUI JobUI OGoMailFilter OGoResourceScheduler PropertiesUI
address@hidden:~$ ls /usr/local/lib/opengroupware.org-1.0a/webui/
AddressUI.lso LSWScheduler.lso OGoProject.lso OGoUIElements.lso
The .lso are (basically) empty bundles.

Another issue is that bundles need to be stored in application specific subdirectories. This AFAIK can't be done with Foundation API. Eg in SOPE we lookup template builder bundles in
Also note the versioning of bundles, which is crucial!

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?

Maybe. Something like that is time consuming and hard to document.

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.

Cocoa Foundation also seems to be significantly slower. But this might also be because Apple machines are slower. As mentioned, hard to get exact numbers.

Its also on my todolist to run OGo on MacOSX through Shark.

The perf-difference might be due to Unicode vs 8bit strings, though I don't think it should matter.

Probably easy to solve, but might need some KCacheGrinding.
It's a pretty good tool.

Its awesome. Shark is even better though (mostly because it doesn't require emulation).

For many of the issues initially I suspect we can optimise well through source review.

Won't be a suitable approach for OGo (way too much sourcecode). A tool is required to detect hotspots.

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

Unfortunately its not enough that _you_ agree. It would need to be a general agreement that this is enforced and it also has quite some effects on release and maintenance processes. Currently GNUstep only puts out new - soname incompatible - versions and provides no maintenance procedures on old packages at all.

Anyway, we could have our own release packages which follow strict policies as required by us. It wouldn't prevent code sharing.

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

Hm, yes, though it bites a bit with Foundation compatibility. Cocoa Foundation is quite bloated nowadays (eg XML support, NSURL HTTP client, Scripting, etc).

The debate about this particular code fragment was about BOOL generally and has a wider scope.

This was already discussed in a past thread. AFAIK with no general agreement that ==YES is dangerous.

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.

The build process is quite simple and well documented. Basically
  cd SOPE; ./configure; make install
  cd OGo;  ./configure; make install

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 don't remember. The process didn't properly startup, I think it was some resource lookup issue with timezone files (probably for NSLog output).

I'm pretty sure it could be resolved quite quickly with a little dedicated effort.

I guess so.


reply via email to

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