discuss-gnustep
[Top][All Lists]
Advanced

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

RE: problem porting sogo to use gnustep-make 2


From: Sebastian Reitenbach
Subject: RE: problem porting sogo to use gnustep-make 2
Date: Mon, 21 Jan 2008 09:59:12 +0100

nicola.pero@meta-innovation.com wrote: 
> 
> > compilation against gnustep-base 1.13. failed at NGResourceLocator.m 
because 
> > GSWebApplicationsDirectory and friends are not defined in 
NSPathUtilities.h, 
> > so at least gnustep-base 1.14 would be needed.
> 
> I suppose you could check for the gnustep base version (there are macros
> for that) and only include the new code if gnustep-base >= 1.14.  Maybe
> it's not worth the effort though.  Requiring gnustep-base >= 1.14 seems
> reasonable. :-)
> 
> 
> > This would also break compatibility with at least libFoundation, 
> 
> Not sure why - the old code to use GNUSTEP_PATHLIST to create the GNUstep
> search path is still there ... so if it worked before, it should keep
> working ? ;-)
> 
> Or maybe you mean that gnustep-make v2 + libFoundation wouldn't work - 
which
> is right, but it's because libFoundation has not been updated to work with
> gnustep-make v2. :-(
yeah, I meant with the missing #if below, it breaks.

> 
> 
> > also an #if GNUSTEP_BASE_LIBRARY was missing around the method 
> > standardSearchPathsForGNUstepPath, so that compilation will not break 
when 
> > compiling against other foundations libraries.
> 
> Thanks - you are right - thanks for adding this :-)
> 
> 
> > I never tried to use gnustep-base >= 1.14 with gnustep-make < 2, so I 
don't 
> > know if this would work at all.
> 
> IIRC gnustep-base >= 1.14 requires gnustep-make >= 2.0.0
> 
> 
> > Therefore I think there is no reason to keep the gnustep-make 1 
compatibility 
> > in the sope makefiles.
> 
> It might be needed to keep libFoundation working for the time being.
> 
> Actually, it might be worth checking if libFoundation works with 
gnustep-make
> v2 - and if not, to make it work.  You mostly need a working 
implementation
> of NSPathUtilities.  The current implementation based on GNUSTEP_PATHLIST
> makes no sense with gnustep-make v2, but it should be easy to write a very
> simple implementation where all paths are hardcoded in the library at
> configure time; you won't have the ability to relocate things at runtime 
> by editing the GNUstep config file, but otherwise it would be pretty 
enough.
> 
> I had a look but then found that I can't even regenerate libFoundation's 
configure
> script using autoconf 2.61 (recursion limit exceeded) so that needs fixing 
first. :-/

yeah, I did not yet bothered to check whether libFoundation is working, but 
I think I can update the NSPathUtilities stuff to work with gnustep-make 2.

Sebastian





reply via email to

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