[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
- problem porting sogo to use gnustep-make 2, Sebastian Reitenbach, 2008/01/10
- RE: problem porting sogo to use gnustep-make 2, Nicola Pero, 2008/01/10
- RE: problem porting sogo to use gnustep-make 2, Nicola Pero, 2008/01/14
- RE: problem porting sogo to use gnustep-make 2, Sebastian Reitenbach, 2008/01/14
- RE: problem porting sogo to use gnustep-make 2, Nicola Pero, 2008/01/14
- RE: problem porting sogo to use gnustep-make 2, Sebastian Reitenbach, 2008/01/21
- RE: problem porting sogo to use gnustep-make 2, Nicola Pero, 2008/01/21
- RE: problem porting sogo to use gnustep-make 2,
Sebastian Reitenbach <=