Spin off of bug 668953 (see bug 668953 comment 91)
- we'll need to define 10.7 SDK cocoa symbols when using the 10.6 SDK or lower.
- we need a way to tell which SDK we're using in compiled
(In reply to Zbigniew Braniecki [:gandalf] from comment #0)
> - we need a way to tell which SDK we're using in compiled code
MAC_OS_X_VERSION_MAX_ALLOWED is exactly that, even though it's very confusingly named. We already use it, for example here:
#if !defined(MAC_OS_X_VERSION_10_7) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7
for the enum and interface definitions in nsChildView.h would be exactly the right thing to do here.
I now agree, Benoit. I'm about to try it out with a 10.7 SDK build on OS X 10.7.
If that works (which it should), I'll post a patch and ask you to review.
> I now agree, Benoit.
Oops. I now agree with both Benoit (bug 668963 comment #98) and Markus.
Created attachment 552673 [details] [diff] [review]
Comment on attachment 552673 [details] [diff] [review]
Landed on mozilla-central:
> instead of
> #ifdef __LP64__
As long as we continue to use the 10.5 SDK for 32-bit builds, we can't
use the patch for bug 668953 in 32-bit builds -- the code compiles on
10.6, but won't link. That's why I used #ifdef __LP64__.
Benoit suggested we might use MAC_OS_X_VERSION_MIN instead. But I'd
feel obliged to double-check the docs and do test compiles, and we
don't have time for that. I've been using __LP64__ all along, and
know that it works.
If we haven't replaced __LP64__ by the time we stop using the 10.5
SDK, we can just drop it -- it'll no longer be needed.
There's been talk of dropping the 10.5 SDK even before we drop support
for running on OS X 10.5. See bug 674655. But this might not work
(In reply to Steven Michaud from comment #6)
> > instead of
> > #ifdef __LP64__
> As long as we continue to use the 10.5 SDK for 32-bit builds, we can't
> use the patch for bug 668953 in 32-bit builds -- the code compiles on
> 10.6, but won't link.
Which part exactly? And why? Have you tested it?
Sorry to be so inquiring, but I'd really like to understand this :)
It has to do with "blocks". See bug 668953 comment #67.
Oh, right. I had forgotten that the interface definition has blocks, too (and not only the chunk of code in nsChildView.mm). OK, thanks.