From gnustep-port@opengroupware.org Tue Mar 15 00:41:15 2005 From: gnustep-port@opengroupware.org (Stefan Huehner) Date: Tue, 15 Mar 2005 01:41:15 +0100 Subject: [OGo-GNUstep-Port] compile problem with sope-gdl1 with gnustep Message-ID: <20050315004115.GE27782@kt-gmbh.de> Hi, i'm trying to compile sope without libFoundation but with gnustep-base. When configuring sope with --enable-debug i trigger a compile error in the sope-gdl1/GDLAccess directory. In the FoundationExt-sub-directory the object-files arent create in shared_debug_obj but in shared_obj there the following steps fail. By adding the following to lines to the FoundationExt GNUMakefile the problem goes away. (Lines borrowed from GDLAccess-Makefile). +-include ../../../config.make +include ../../common.make Regards, Stefan Huehner From gnustep-port@opengroupware.org Tue Mar 15 01:40:31 2005 From: gnustep-port@opengroupware.org (Helge Hess) Date: Tue, 15 Mar 2005 02:40:31 +0100 Subject: [OGo-GNUstep-Port] compile problem with sope-gdl1 with gnustep In-Reply-To: <20050315004115.GE27782@kt-gmbh.de> References: <20050315004115.GE27782@kt-gmbh.de> Message-ID: On 15. Mrz 2005, at 01:41 Uhr, Stefan Huehner wrote: > i'm trying to compile sope without libFoundation but with gnustep-base. > When configuring sope with --enable-debug i trigger a compile error in > the sope-gdl1/GDLAccess directory. In the FoundationExt-sub-directory > the object-files arent create in shared_debug_obj but in shared_obj > there > the following steps fail. By adding the following to lines to the > FoundationExt > GNUMakefile the problem goes away. (Lines borrowed from > GDLAccess-Makefile). > > +-include ../../../config.make I did add that in r656. > +include ../../common.make I left that as GNUSTEP_MAKEFILES/common.make. Is it really required to fix the issue? What is the error? ../../common.make cannot be used, since it uses relative pathes. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From gnustep-port@opengroupware.org Tue Mar 15 10:31:45 2005 From: gnustep-port@opengroupware.org (Stefan Huehner) Date: Tue, 15 Mar 2005 11:31:45 +0100 Subject: [OGo-GNUstep-Port] compile problem with sope-gdl1 with gnustep In-Reply-To: References: <20050315004115.GE27782@kt-gmbh.de> Message-ID: <20050315103145.GF27782@kt-gmbh.de> On Tue, Mar 15, 2005 at 02:40:31AM +0100, Helge Hess wrote: > On 15. Mrz 2005, at 01:41 Uhr, Stefan Huehner wrote: > >i'm trying to compile sope without libFoundation but with gnustep-base. > >When configuring sope with --enable-debug i trigger a compile error in > >the sope-gdl1/GDLAccess directory. In the FoundationExt-sub-directory > >the object-files arent create in shared_debug_obj but in shared_obj > >there > >the following steps fail. By adding the following to lines to the > >FoundationExt > >GNUMakefile the problem goes away. (Lines borrowed from > >GDLAccess-Makefile). > > > >+-include ../../../config.make > > I did add that in r656. This fixes the Problem. Thx > > >+include ../../common.make > > I left that as GNUSTEP_MAKEFILES/common.make. Is it really required to > fix the issue? What is the error? > > ../../common.make cannot be used, since it uses relative pathes. This change isn't necessary. The orther line fixed the build. Regards, Stefan From gnustep-port@opengroupware.org Tue Mar 15 13:53:31 2005 From: gnustep-port@opengroupware.org (Stefan Huehner) Date: Tue, 15 Mar 2005 14:53:31 +0100 Subject: [OGo-GNUstep-Port] stringByReplacingString: withString: -> FIXME Message-ID: <20050315135331.GG27782@kt-gmbh.de> Hi, while trying to build with gnustep i get several FIXME's i.e. like this: Logic/LSSearch/LSBaseSearch.m #if LIB_FOUNDATION_LIBRARY val = [val stringByReplacingString:@"'" withString:@""]; #else # warning FIXME: incorrect implementation for this Foundation library! #endif I'm searching for an easy and maintainable way to fix these. In sope-core/NGExtension/ i noticed several method which are added to i.e. NSString. When we would add stringByReplacingString: withString: there we could transparently use it everywhere else, without cluttering the whole codebase with #if's. I would like to get some feedback before doing changes 'the wrong way' (tm) Regards, Stefan From gnustep-port@opengroupware.org Tue Mar 15 13:55:37 2005 From: gnustep-port@opengroupware.org (Helge Hess) Date: Tue, 15 Mar 2005 14:55:37 +0100 Subject: [OGo-GNUstep-Port] stringByReplacingString: withString: -> FIXME In-Reply-To: <20050315135331.GG27782@kt-gmbh.de> References: <20050315135331.GG27782@kt-gmbh.de> Message-ID: On Mar 15, 2005, at 14:53, Stefan Huehner wrote: > Logic/LSSearch/LSBaseSearch.m > > #if LIB_FOUNDATION_LIBRARY > val = [val stringByReplacingString:@"'" withString:@""]; > #else > # warning FIXME: incorrect implementation for this Foundation library! > #endif > > I'm searching for an easy and maintainable way to fix these. In > sope-core/NGExtension/ i noticed several method which are added to > i.e. NSString. > When we would add stringByReplacingString: withString: there we could > transparently use it everywhere else, without cluttering the whole > codebase with #if's. Yes. Actually I think NGExtension already provides a method for the above thing. Note that the code is also supposed to work on Cocoa, so you can remove the #if only if you already have tested code for that Foundation. But take care not to aggressivly remove #ifdef'ed things which you "think" are correct without testing. There are minor differences/bugs in all Foundations which might need to get worked around. (though I have no example in my mind) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From gnustep-port@opengroupware.org Tue Mar 15 14:14:06 2005 From: gnustep-port@opengroupware.org (Stefan Huehner) Date: Tue, 15 Mar 2005 15:14:06 +0100 Subject: [OGo-GNUstep-Port] stringByReplacingString: withString: -> FIXME In-Reply-To: References: <20050315135331.GG27782@kt-gmbh.de> Message-ID: <20050315141406.GH27782@kt-gmbh.de> On Tue, Mar 15, 2005 at 02:55:37PM +0100, Helge Hess wrote: > > > Yes. Actually I think NGExtension already provides a method for the > above thing. Note that the code is also supposed to work on Cocoa, so > you can remove the #if only if you already have tested code for that > Foundation. > > But take care not to aggressivly remove #ifdef'ed things which you > "think" are correct without testing. There are minor differences/bugs > in all Foundations which might need to get worked around. (though I > have no example in my mind) Hmm, i have got no access to an mac for compile and run on this foundation therefore i can only directly test on libFoundation provided in ThirdParty and with gnustep-base. Is there an accessible mac machine available somewhere to test there? In general some more or less automated tests for these methods in question would be nice. So that the different foundations ca be encapsulated in NGExtension and tested for correct behaviiur there... Regards, Stefan From gnustep-port@opengroupware.org Tue Mar 15 14:25:39 2005 From: gnustep-port@opengroupware.org (Helge Hess) Date: Tue, 15 Mar 2005 15:25:39 +0100 Subject: [OGo-GNUstep-Port] stringByReplacingString: withString: -> FIXME In-Reply-To: <20050315141406.GH27782@kt-gmbh.de> References: <20050315135331.GG27782@kt-gmbh.de> <20050315141406.GH27782@kt-gmbh.de> Message-ID: On Mar 15, 2005, at 15:14, Stefan Huehner wrote: > Hmm, i have got no access to an mac for compile and run on this > foundation therefore i can only directly test on libFoundation provided > in ThirdParty and with gnustep-base. Is there an accessible mac machine > available somewhere to test there? I don't think so. You can always point out gstep-base changes you have made on macosx@opengroupware.org so that someone can verify that it also works on Cocoa. Until that is done you can't remove an appropriate #if. > In general some more or less automated tests for these methods in > question would be nice. So that the different foundations ca be > encapsulated in NGExtension and tested for correct behaviiur there... Definitely and contributions in that direction are very very welcome :-) ZNeK started to use OCUnit for tests in NGiCal, maybe the same could be used for NGExtension unit tests. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org