Re: Cross OS version UB development
Re: Cross OS version UB development
- Subject: Re: Cross OS version UB development
- From: Jim Wintermyre <email@hidden>
- Date: Sat, 24 Feb 2007 12:11:15 -0800
>>>>> It is probably safer to create two targets in your project, one
for Intel only (using 10.4) and one for PPC (10.2) and meld
them together using lipo in a 3rd target that has only a run
script build phase.
Why? Xcode supports building a UB directly for you (by default
Release configuration does this while Debug only build the
platform you are running on). You don't need to make it harder
on yourself. This capability works fine so I suggest you use it.
Because I'm not an Xcode wizard.
You don't have to be.
Right. And you have to be a terminal wizard to set up script phase
that lipos your binaries. This was necessary in Xcode 2.1, but
those days, luckily, are long gone.
I wish that were true. Unfortunately, Xcode's automatic Universal
Binary creation facility always applies exactly the same rules to
exactly the same set of files for both the ppc and i386 editions of a
Universal Binary. Any deviation from this prescription requires that
the two editions be lipo'd together manually.
In my case, the real-time lossless SheerVideo codecs have a large
number of G4-specific, G5-specific, and Intel-specific functions
containing vector-processor-specific assembler code and requiring
processor-specific optimization flags. Because in gcc all
optimization flags can only be specified on the command line, not as
#pragmas in the source code, this means I have many processor-
specific source files with processor-specific flags.
When building for just ppc, or just i386, I can fake out Xcode by
applying symbolic flags (e.g. $(G4Flags), $(G5Flags)) to those files,
and defining those symbols as environment variables specific to the
configuration. Thus $(G4Flags) is defined away as an empty string for
the i386 configurations, and as actual G4 AltiVec optimization flags
for the ppc configurations.
But the way Xcode works, a universal binary is a single configuration
with two architectures. So there's no way to give it architecture-
specific flags. And if I define the flags for both architectures,
then gcc barfs when Xcode feeds the C preprocessor unrecognized flags
for the wrong processor.
In my projects, I actually use *targets* for debug/release, even
though all the Xcode docs suggest to use configs for this... The
main reason I do this is that this is the only way to actually have
different files included in the target in the debug case. Then I
have different configurations set up for the architectures - PPC,
Intel, and Universal. I used to have the Universal setup configured
as just a script phase, which manually lipo'd the outputs of the PPC
and Intel configs. I'm certainly no script wizard, and it wasn't
that hard to set up. This allows you to have completely independent
settings for the PPC and Intel builds, so it's a little more flexible
than the automatic Xcode method for setting up a UB. Also, for my
day-to-day development I can select the config for the machine I'm
developing on, and compiles are then twice as fast. Then I can
switch to the Universal config when I need to do a release build, or
a test build for multiple architectures.
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden