[CMake] Re: CMake Marketing

[E. Wing]

Yes, it should be just a few compiler flags. This looks generally
correct (with a few caveats).
SDK=/Developer/SDKs/MacOSX10.4u.sdk
CFLAGS= -isysroot ${SDK} -arch ppc -arch ppc64 -arch i386
LDFLAGS= -isysroot ${SDK} -syslibroot,${SDK}

Caveat 1: You probably should provide a menu option for which
architecture(s) you want to compile for. For example, I generally
don't see ppc64 used in most projects as there are some limitations in
it, especially if you have GUI code. Also, if you are linking against
other libraries that are not already compiled for that specific
archtecture, the link will fail. So keeping it on when not wanted will
cause people problems. Also, it is a separate compile for each
archtecture so the build process time takes twice or three time as
long. For development, it is convenient to keep this off, but for
deployment, you turn it on.

Caveat 2: Get the -arch ppc -arch i386 order correct. There was a bug
early on where -arch i386 -arch ppc would fail. I hope they fixed that
by now, but I embarrassed a few people by spotting this in front of
the VP of Developer Tools back at WWDC :)

Caveat 3: Be prepared to drop the SDK flags. Currently on PPC Tiger
systems, you need the -lsysroot and -lsyslibroot to specify where the
headers and Universal Binaries you compile and link against are
located. This is because Tiger did not ship with Universal Binaries.
But I think on the Intel Macs (I haven't been able to confirm this
though), everything is already built Universal. So setting the SDK
stuff isn't required. Certainly by Leopard, everything will be unified
again, so you won't want to use these flags. Perhaps you should do
some OS version checks and architecture checks to decide if you should
activate the SDK stuff. And obviously, pre-Tiger OS's won't have this
SDK available.

Caveat 4: Default search paths for libraries and headers change when
you use the SDK stuff. This isn't generally a problem for Apple
included stuff, but if you have 3rd party frameworks for example, the
build system won't find them as usual. This requires an explicit -F
flag (which I have mentioned as a problem in the Findosg*.cmake
modules I submitted). I think this also affects include files and
dylibs.



There is also some advanced stuff you might be able to do which may or
may not be useful.

For example, it looks like Bob was looking at architecture specific SDKs via:
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk
SDKROOT_ppc64 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk

I've also been experiementing with architecture specific gcc versions:
GCC_VERSION_i386
GCC_VERSION_ppc

The biggest problem that has come up is that Xcode and gcc 4.0 have
changed functionalitly and dependencies in some of the lower level
system libraries. The big result is that a lot of code that used to
work in 10.2 Jaguar won't work any more, so a lot of developers are
trying tricks to see if they can create a Universal Binary without
dropping support for pre-10.3.9.

Some of these tricks require manual invocation of lipo, while others do not.

Thanks,
Eric


On 12/20/05, William A. Hoffman <billlist at nycap.rr.com> wrote:
> At 09:09 PM 12/20/2005, E. Wing wrote:
>
> >There is also the lack of Universal Binary support, but I trust this
> >will ultimately be addressed.
>
> I think CMake can do this right now.  As far as I can tell support for
> Universal Binaries means adding a few flags to the compiler.  Then, do
> a bunch of stuff to your code.
>
> Here is a site that has the flags:
> http://bob.pythonmac.org/archives/category/macosx/universal-binaries/
>
> If someone were to verify that these flags work, I suppose we could add
> them to the cmake platform files for the Mac.   To use Xcode, I guess it
> is just a flag that needs to be set in the project file.
>
> -Bill
>
>
>
>
>
>