gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo InvoiceApplication

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> On 02.01.2008, at 17:13, Sebastian Reitenbach wrote:
> >>> BTW: I think the GNUstep guys pretty much agree with me on  
> >>> this :-) In
> >> fact *we* could probably contribute a stable GNUstep release branch.
> > You mean a second gnustep-base stable?
> 
> No, a *first* gnustep-base stable. As far as I know there has never  
> been an ABI stable GNUstep release branch.
> 
> > there exists already a gnustep-base
> > stable version? right now it is 1.14.2 I think, the unstable stuff  
> > is at
> > 1.15.2.
> 
> Those are ABI unstable versions, comparable to SOPE 4.7.x OGo 1.1.x.
OK, then I do not understand why they have a -base stable and unstable, but 
that is then another story.

> 
> >> And then instead, keeping the existing ogo stuff compiling against  
> >> the
> > (dead) libFoundation?
> 
> Its not '(dead)', its perfectly working code.
ok, then not dead, but in some kind of "Dornr=F6schenschlaf" ;)

> 
> > Then this will make the existing objective-c ogo die
> > sooner than later I think. At least, when ogo will be compatible to
> > gnustep-base, it might attract one or another people to develop, as  
> > I have
> > seen happen to sogo. But as long as ogo depends on libFoundation,  
> > this will
> > very unlikely happen.
> 
> I don't believe in that, but anyways. Nothing against moving to  
> gnustep-base.


> 
> As far as I'm concerned the ObjC codebase will not die. Just like  
> libFoundation it will go into maintenance mode for years to come. Its  
> working and quite stable, why drop it?
e.g. libFoundation is not working on OpenBSD, and the patches to make it 
work are since a long time in the bugzilla and nothing happend with them. 
In my eyes, its a bit too stable, or missing utf-8 support. I doubt that 
someone will add it in the near future, but I might be wrong.
IIRC in some other older threads, you also pointed out that it would be 
great to have that utf-8 support.

Nevertheless, to get ogo and sope installed and also working within a 
GNUstep tree, we should define relative paths to some of the existing 
variables:
In GNUstep, the following variables are defining standard locations:

#
# SYSTEM domain
#
GNUSTEP_SYSTEM_APPS        ?=3D /usr/GNUstep/System/Applications
GNUSTEP_SYSTEM_ADMIN_APPS  ?=3D /usr/GNUstep/System/Applications/Admin
GNUSTEP_SYSTEM_WEB_APPS    ?=3D /usr/GNUstep/System/Library/WebApplications
GNUSTEP_SYSTEM_TOOLS       ?=3D /usr/GNUstep/System/Tools
GNUSTEP_SYSTEM_ADMIN_TOOLS ?=3D /usr/GNUstep/System/Tools/Admin
GNUSTEP_SYSTEM_LIBRARY     ?=3D /usr/GNUstep/System/Library
GNUSTEP_SYSTEM_HEADERS     ?=3D /usr/GNUstep/System/Library/Headers
GNUSTEP_SYSTEM_LIBRARIES   ?=3D /usr/GNUstep/System/Library/Libraries
GNUSTEP_SYSTEM_DOC         ?=3D /usr/GNUstep/System/Library/Documentation
GNUSTEP_SYSTEM_DOC_MAN     ?=3D /usr/GNUstep/System/Library/Documentation/man
GNUSTEP_SYSTEM_DOC_INFO    ?=3D /usr/GNUstep/System/Library/Documentation/info

#
# SYSTEM domain, variables that are fixed to subdirs of LIBRARY
#
GNUSTEP_SYSTEM_APPLICATION_SUPPORT =3D 
$(GNUSTEP_SYSTEM_LIBRARY)/ApplicationSupport
GNUSTEP_SYSTEM_BUNDLES             =3D $(GNUSTEP_SYSTEM_LIBRARY)/Bundles
GNUSTEP_SYSTEM_FRAMEWORKS          =3D $(GNUSTEP_SYSTEM_LIBRARY)/Frameworks
GNUSTEP_SYSTEM_PALETTES            =3D 
$(GNUSTEP_SYSTEM_LIBRARY)/ApplicationSupport/Palettes
GNUSTEP_SYSTEM_SERVICES            =3D $(GNUSTEP_SYSTEM_LIBRARY)/Services
GNUSTEP_SYSTEM_RESOURCES           =3D 
$(GNUSTEP_SYSTEM_LIBRARY)/Libraries/Resources
GNUSTEP_SYSTEM_JAVA                =3D 
$(GNUSTEP_SYSTEM_LIBRARY)/Libraries/Java

but in general, these paths can be chosen very arbitrary, when installing 
and configuring gnustep-make. So for the sope/ogo applications and 
resources, I think we should define relative paths to these locations.
With these defined, I could start to make sope/ogo a bit more flexible in 
these ways.

kind regards
Sebastian