On 26 Feb 2008, at 4:54 PM, Adam Maxwell wrote: > In article <[EMAIL PROTECTED]>, > Christiaan Hofman <[EMAIL PROTECTED]> wrote: > >> On 26 Feb 2008, at 2:19 AM, Adam R. Maxwell wrote: >> >>> In article >>> <[EMAIL PROTECTED]>, >>> "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: >>> >>>> I just tried to replace the static functions in objc.h with custom >>>> functions, and that together with some checks for MAX instead of >>>> MIN makes >>>> it possible to compile with 10.4+10.5 deployment. No idea if there >>>> should be >>>> other fixes though. >>> >>> That will probably work as long as you don't compile for the 64 bit >>> runtime, where isa no longer exists. The Omni framworks aren't 64 >>> bit >>> clean, but it looks like they might be trying to move in that >>> direction. >>> Note that you have to close all projects and edit >>> Omni-Global-Common.xcconfig to use the 10.5 SDK; looks like you're >>> still >>> using 10.4u, also in BibDesk-Common.xcconfig. >>> >> >> Didn't think about those, because I have never bothered with >> configurations. > > You might be able to override from the project settings, but it causes > hard-to-find problems. You might have to delete per-project overrides > to make the xcconfig work again. >
I have done that now. I also tried to share the config files with other subprojects, but that does not work because it sontains versioning and preset header settings. >> >>> There are other problems as well, such as NSRecordAllocationEvent; >>> you >>> might have to #if that out. Long term it would be better just to >>> get >>> rid of the Omni frameworks entirely. >> >> Actually, I am totally confused about that one. The Debug.h header in >> the 10.4u SDK says that it should have 2 arguments for >> NSObjectInternalRefIncrementedEvent, while in OFObject they give it 5 >> on 10.5. Who's wrong? > > Interesting. In 10.4u, I see > > FOUNDATION_EXPORT void NSRecordAllocationEvent(int eventType, ...); > > so it apparently expects a varargs list. The examples only pass two > arguments, so I've no idea what will happen if you don't give it a nil > terminated list. It does not need to be nil terminated, I think. The number of arguments may depend on the eventType (though perhaps that's only for some private eventTypes, or for legacy support). However it should match, and in fact in OmniFoundation it does not match with the examples in the header. > That header also says the function should never be > called in shipping code, so getting rid of it should be safe. Actually it says that it should not be used with most of the eventTypes, but the one that is used should be allowed. Anyway, the only reason seems to be OOM support. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
