gstep-make 2.0 Re: gstep-base Re: [OGo-Developer] OGo Invoice Application

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> On 02.01.2008, at 07:29, Sebastian Reitenbach wrote:
> > the following relative
> > path directory name is hardcoded: Library/Libraries/Resources/NGObjWeb
> > but with gnustep-make 2 I would use the GNUSTEP_WEB_APPS to define  
> > the place
> > where this stuff should be installed.
> 
> OK, but how would it continue then? SOPE must know where to search,  
> und unlike the current solution using "GNUSTEP_WEB_APPS" at the  
> compile time (eg passing it in using -D...) would make the binary non- 
> relocatable! (because GNUSTEP_WEB_APPS is indeed a compile-time path).
> 
I don't understand why it then is less relocatable than it is right now.
I did not meant to define an absolute path, just only a relative subdir.

> So what is required is a way to query GNUstep for the value of  
> "GNUSTEP_WEB_APPS".
> 
> [BTW: GNUSTEP_WEB_APPS is not the best place for SOPE stuff. This is  
> for the gnustep-web binaries]
Anything better in mind? I'm open for everything, and I think Nicola would 
add also new Variables/path locations if they are reasonable. 

> 
> > This is better done in: DocumentAPI/OGoScheduler/GNUmakefile
> ..
> > # TODO: this should rather check the makefile version!
> > ifeq ($(FHS_INSTALL_ROOT),)
> > ifeq ($(FOUNDATION_LIB),fd)
> > RESOURCES_DIR=$(GNUSTEP_LOCAL_ROOT)/Libraries/Resources/OGoScheduler
> > else
> > RESOURCES_DIR=$(GNUSTEP_LOCAL_ROOT)/Library/Libraries/Resources/ 
> > OGoScheduler
> > endif
> > else
> > RESOURCES_DIR=$(FHS_INSTALL_ROOT)/share/opengroupware.org-1.1
> > endif
> >
> > libOGoScheduler_CPPFLAGS += \
> >  -DRESOURCES_DIR="$(RESOURCES_DIR)"
> 
> Actually I would consider that b0rked because it makes the binary non- 
> relocatable. Not sure, probably this is from times before I wrote the  
> locator class in NGExtensions.
ah, so I should take a look into this one, then I'll understand the 
relocatable thing a bit more I hope.

> 
> >>>
> > I just took a quick look in the makefiles of libFoundation, there is  
> > a lot
> > of magic stuff going on. So maybe not that easy as the rest. I'd  
> > more likely
> > focus on getting ogo compile and run against gnustep-base instead of  
> > wasting
> > time with libFoundation.
> 
> Well, I get the point, but if we want to commit the patches it should  
> (must?) work with the packaging! Adopting them to use gstep-make 2 is  
> probably no big deal and a good starting point, but reworking the  
> packages for gnustep-base will be quite a bit of work.
> (and for some reason I guess that you won't do the package work ... ;-)
I guess I don't know much enough to make the packaging stuff work in a 
reasonable time, but I can take a look.

I do for OpenBSD, and it is mostly ready ;)

At least, I'll try to install the GNUstep-make 2.0.0 rpm and the 
libFoundation/ogo-gnustep rpm's and then recompile ogo against libfoundation 
using gnustep-2.0.0 to make sure that both can live next to each other and 
don't produce conflicts.

> 
> > what about releasing a ogo 1.1.8, maybe including the AsteriskDialer  
> > and
> > zOGI ;) as the top new highlights, last gnustep-make 1.13 and  
> > libFoundation version, and then concentrating in trunk to compile  
> > against gnustep-make 2 and gnustep-base.
> 
> Personally I have no objections, but moving to gnustep-base sounds  
> only viable to me if we all agree to drop packaging. I somehow doubt  
I would prefer installation from source on systems. Maybe then it would be 
viable to add some more targets to the GNUmakefile, e.g.:
create-system-environment::
create-initial-database::

that then would do the stuff what the -meta packages would have done when 
they would be installed via rpm.
When the whole process then gets well documented in a INSTALL file in the 
sources, then I think, this will stop the "where do I find rpm for Distri 
XXX", or other similar question that show up there from time to time on the 
users ml.

At least, for OpenBSD I'd like to create ports files. I do all gnustep 
upgrade stuff, because the gnustep-make and gnustep-base packages are well 
maintained there. I'd like to start creating ports on them?


> that Frank will have the time to adopt the RPMs/DEBs for gnustep-base  
> in the near future (but feel free to ask/convince him ;-).
At least for the suse 10.3 rpm's i can take a look, and test these. I don't 
have debian running somewhere, so unable to test.

> 
> BTW: we would also need to create a gnustep-make/gnustep-base vendor  
> branch to stabilize it for OGo usage.

also what about sogo? At least there  the packaging constraint is not a 
problem, as just there are none. But the sogo makefiles have to be updated 
too. Wolfgang, do you are here on the list too?
I could update these for sogo too, as I would like to see sogo to work on 
OpenBSD too, and then create ports ;)

cheers
Sebastian