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: Nicola Pero
Subject: RE: problem porting sogo to use gnustep-make 2
Date: Mon, 21 Jan 2008 09:16:40 +0100 (CET)

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


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

Thanks





reply via email to

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