[Craig Hockenberry]

I'm trying to build the frameworks for the first time using Xcode 3.1. I'd like to see the OmniDataObjects.framework that Tim introduced at C4.

Per the Read Me, I'm doing "./Scripts/build Frameworks" from the OmniGroup folder.

The build is placing the resulting frameworks in /Users/Shared/craig/InstalledProducts. It appears that I can control the resulting location with either the OMNI_PRODUCT_DIRECTORY environment variable or a Xcode user default named PBXProductDirectory. Where do you guys recommend putting both the Debug and Release versions of the frameworks? In /Library/Frameworks or somewhere else? What's the best way to set PBXProductDirectory? Looked around in Xcode preferences and didn't see anything...

I'm also having problems with the OmniDataObjects.xcodeproj -- when I open it, I see both OmniBase.framework and OmniFoundation.framework highlighted in red (and doing Get Info on them shows the full path pointing to the target in the build folder.)

If I try to update the path to these two frameworks to the ones installed in the "InstalledProducts" folder, get compilation errors for the prefix files:

/Users/craig/Downloads/OmniGroup/Frameworks/OmniDataObjects/OmniDataObjects_Prefix.h:10:30: error: OmniBase/OmniBase.h: No such file or directory

I'm probably doing something stupid here—I'd appreciate it if you could tell me what it is :-)

-ch

[Tim Wood]

I fear the fleshy palm!

If you look in Xcode's Building pref pane, you can set a separate build location for build products and intermediates. We do all our builds with something like:

Place Build Products in: [x] Customized Location: /Users/Shared/user-name/Products
Place Intermediate Build Files in: [x] With build products

This will set the defaults in question and will allow the frameworks to find each other. Also, the separate build directory keeps Xcode from junking up our source directory and generally is nicer in our opinion.

Longer term, I'm hoping we can release our real build scripts, but it is unclear if that would make things simpler for _you_ or just simpler for _us_ =)

[Tim Wood]

I should also mention, that we're working on getting OWF to build (or we may remove it if Ken/Wim deem that better). It's suffered some bit rot in our recent updates and needed a bit of love. I don't think its seeing a lot of use these days, but it should at least build. Yeesh!

[Craig Hockenberry]

Looks like there are some problems building OIF because of OWF bitrot, too. I removed OWF from the Scripts/projectList file and then got this:

ProcessPCH /Users/Shared/craig/Products/Debug/SharedPrecompiledHeaders/OIF_Prefix-cqxuumniwlktcxaywcavcawfogmj/OIF_Prefix.h.gch OIF_Prefix.h normal i386 objective-c com.apple.compilers.gcc.4_0
<snip>
/Users/craig/Downloads/OmniGroup/Frameworks/OIF/OIF_Prefix.h:14:20: error: OWF/OWF.h: No such file or directory
** BUILD FAILED **

The following build commands failed:
OIF (Framework):
ProcessPCH /Users/Shared/craig/Products/Debug/SharedPrecompiledHeaders/OIF_Prefix-cqxuumniwlktcxaywcavcawfogmj/OIF_Prefix.h.gch OIF_Prefix.h normal i386 objective-c com.apple.compilers.gcc.4_0
(1 failure)

Build failed in (OmniGroup/Frameworks/OIF)

The unit tests are complaining, too:

ProcessPCH /Users/Shared/craig/Products/Debug/SharedPrecompiledHeaders/OAUnitTests_Prefix-bsjkqsklhqencnhalyiboprubfbz/OAUnitTests_Prefix.h.gch Tests/UnitTests/OAUnitTests_Prefix.h normal i386 objective-c com.apple.compilers.gcc.4_0
<snip>
/Users/craig/Downloads/OmniGroup/Frameworks/OmniAppKit/Tests/UnitTests/OAUnitTests_Prefix.h:15:40: error: SenTestingKit/SenTestingKit.h: No such file or directory

<snip>
** BUILD FAILED **

The following build commands failed:
OAUnitTests:
ProcessPCH /Users/Shared/craig/Products/Debug/SharedPrecompiledHeaders/OAUnitTests_Prefix-bsjkqsklhqencnhalyiboprubfbz/OAUnitTests_Prefix.h.gch Tests/UnitTests/OAUnitTests_Prefix.h normal i386 objective-c com.apple.compilers.gcc.4_0
(1 failure)

Build failed in (OmniGroup/Frameworks/OmniAppKit(OAUnitTests))

[Tim Wood]

Ken uploaded a new zip with fixed OWF and OIF. It looks like the OmniAppKit unit tests are still not building for some reason (not finding SenTestingKit with the 10.5 SDK, it looks like).

We'll keep banging on it, but yeah – anything you don't need can be expunged from the build list as a workaround for now (or as a performance fix for building crap you don't want)

[mperovic]

I have next problem:

The following build commands failed:
OAUnitTests:
CompileC /Users/Shared/miroslavperovic/Products/Builds/OmniAppKit.build/Release/OAUnitTests.build/Objects-normal/ppc/OATestCase.o /Users/miroslavperovic/Development/OmniGroup/Frameworks/OmniAppKit/Tests/UnitTests/OATestCase.m normal ppc objective-c com.apple.compilers.gcc.4_2
CompileC /Users/Shared/miroslavperovic/Products/Builds/OmniAppKit.build/Release/OAUnitTests.build/Objects-normal/i386/OATestCase.o /Users/miroslavperovic/Development/OmniGroup/Frameworks/OmniAppKit/Tests/UnitTests/OATestCase.m normal i386 objective-c com.apple.compilers.gcc.4_2
(2 failures)

Build failed in (OmniGroup/Frameworks/OmniAppKit(OAUnitTests))

I'm using XCode 3.1.3.

[vegangeek]

Re:
"The following build commands failed:
OAUnitTests:
CompileC "

The signature of:
- (BOOL)exceptionHandler:(NSExceptionHandler *)sender shouldLogException:(NSException *)exception mask:(NSUInteger)aMask;

in OATestCase.m has the mask parameter as (unsigned int) instead of the correct (NSUIinteger), and the project has 'treat warnings as errors' on.

So, I changed (unsigned int) to (NSUInteger) in the OATestCase.m - - (BOOL)exceptionHandler:… and it now builds without errors.