Re: Install gnustep-base standalone

[Helge Hess]

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
> /usr/share/nstimezones

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

LibFoundation uses:
helge@move:~$ 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.

Yes.

> 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:
---snip---
helge@move:~$ ls /usr/local/share/opengroupware.org-1.0a/templates
AddressUI      JobUI                OGoMailFilter       
OGoResourceScheduler  PropertiesUI
...
helge@move:~$ ls /usr/local/lib/opengroupware.org-1.0a/webui/
AddressUI.lso      LSWScheduler.lso         OGoProject.lso             
OGoUIElements.lso
...
---snap---
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
  Library/SOPE-4.5/WOxBuilders/MyBuilder.wox
or
  lib/sope-4.5/wox-builders/MyBuilder.wox
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.
> Agreed.

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

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

Greets,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org