[Unison-hackers] XCode expert needed

Steve Kalkwarf steve at kalkwarf.com
Mon Mar 24 09:20:30 EDT 2008


>>This project file uses "Current Mac OS" as its target SDK. For
>>more predictable build results across multiple machines, I'd
>>recommend choosing either the 10.4u SDK or the 10.5 SDK.
>
>OK. If targeting 10.4, would this also run on 10.5?

Yes, the SDK version reflects the available APIs for the build, 
not a minimum system version. You could also target 10.5, and it 
would run on 10.4.

If you look at NSApplication.h, you'll see:

#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5

It's this macro (and other ones like it) that honor the SDK version.


>>Second, if this were my project, I'd change the architecture
>>settings to $(NATIVE_ARCH) for development and "i386 ppc" for deployment.
>
>OK, the only issue is that the caml code is not compiled 
>universally. So to build a UB I need to compile it on several machines.

I would have assumed that the build was universal. There's a technote:

<http://developer.apple.com/opensource/buildingopensourceuniversal.html>

that explains how to make a traditional makefile-type project 
build universally.

>My question was: why does calling xcodebuild with the variable 
>OCAMLLIBDIR set work? It must be configured somewhere in the 
>project (to add this variable to the list of header paths) but 
>searching yielded nothing.

Ah. Because several of the makefiles used that environment 
variable to prefix some paths. For example, the top level 
Makefile, likes 243:244

>tools/%: tools/%.ml
>ocamlc -o tools/$* -I $(OCAMLLIBDIR)/labltk labltk.cma tools/$*.ml

>In any way, I'm now able to launch unison from XCode, so I 
>should be able to debug things better.

Good luck.

Steve



More information about the Unison-hackers mailing list