lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

> E1: On Mac-recent, there is no supported compiler available with source.

I'm confused by this statement. clang/llvm is open source. Apple is
good about pushing their stuff into public llvm before Xcode final
ships. We learned about some new unannounced features in Obj-C before
Apple announced them thanks to this. What do you mean?

>
> M4: Invoking cc is the official way to get a "reasonable" compiler.

I like this idea of changing Lua to invoke cc instead of gcc.


> M5: If you're targeting Mac-recent, there's no compatibility motivation for
> using -m32
> M5.1: If you're targeting Mac-10.6 there is.

Not so much actually. There were only 2 or 3 models of Intel Macs that
were 32-bit only (the lowest end models). This was in the first 6
months of when Apple first introduced Intel Macs. After that, they got
bumped/upgraded and the entire line was 64-bit. This was all back in
2006. Those computers were rare then, and especially now in 2013. (And
those computers shipped with 10.4.)

> E2: I have no clue how you're supposed to develop for 10.6 from Mac-recent,
> since there is no supported compiler.
> E2.1: Note to self: be sure to keep a 10.6 box around for builds, not just
> testing.

That's not how the Apple world works. (I know people not in this world
hate this, but this is how it is.) You always run the latest OS and
build with the latest Xcode tools and target the latest SDK (e.g.
10.8). You set the minimum deployment version to the oldest version
you want to support/run-on (10.6). You keep a 10.6 box around for
testing, never for builds. (This also allows for the easy use of new
APIs. Apple provides some easy ways to test for availability. It is
harder to go the reverse direction.)

Apple/Cocoa/Obj-C is known to do some very slippery runtime checks to
see which SDK you were compiled with. This has resulted in some very
painful/difficult bugs that break when you take an old binary and run
it on a later OS. One recent experience I had was when iPad 3 (retina)
was introduced. If you took my old existing shipping binaries and
installed them on an iPad 3 (compiled with the old SDK), the image
sizes were completely messed up. If I recompiled the code with the
latest SDK with no code changes, the problem cleared up. This is
definitely an Apple caused bug, but I didn't follow the rules of
building with the latest SDK. To be fair to me, they only gave us 1
week notice that the retina iPad was going to exist and appear on
shelves in a matter of days.) I've experienced other similar issues on
both Mac and iOS over the years.


> lhf1: We want to support as many compilers and processor models as
> possible.
>
> J6: The smallest cover for all of these problems is defined(__llvm__) &&
> defined(__i386__)
> J6.1: This applies the hack even to the working Mac-recent clang, but
> without apparent error.

It seems unwise to apply a workaround that alters stuff on already
working versions. I think it should be narrower. If we can isolate the
version numbers of clang that this bug exists in, we can test for
that.
http://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/