504179 - move Gecko 1.9.2 builds to 10.5 SDK

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Jonathan Kew [:jfkthame]]

In order to allow Gecko 1.9.2 (and hence Firefox 3.6) to include features that depend on OS X 10.5, we should switch the builds to use the 10.5 SDK. This will allow us to begin adopting 10.5 APIs in our code.

This does not imply cutting off all support for OS X 10.4; provided we continue using gcc 4.0.x (which is the current default compiler on OS X), and test at runtime for availability of new APIs before using them, the product should continue to work on 10.4, while allowing us to move forward with new feature work.

While switching the builds to OS X 10.5 and the 10.5 SDK, we should keep at least a few 10.4 tinderboxen for the time being, to check for any breakage, until such time as we decide to explicitly drop 10.4 because the compatibility is costing us too much to maintain.

Note that this is *not* a dupe of bug 501436, which requests a compiler version upgrade that would break 10.4 compatibility; it is a less-disruptive subset. If that decision is taken, this issue becomes irrelevant; but if 501436 is not going to be taken for 1.9.2/FF3.6, then this would enable at least some more forward-looking work in the meantime.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

We already build hg-based branches using OS X 10.5 and XCode 3.1. There are no 10.4 builders or unit testers, but there are talos machines for perf testing both 10.4 and 10.5. 

Use of the 10.5 SDK is set in
  http://hg.mozilla.org/mozilla-central/file/tip/build/macosx/universal/mozconfig#l49
which we include in the mozconfig for the builds. 

So what are the requirements here ? Does it have signoff from the appropriate person ?

Comment 2

[Jonathan Kew [:jfkthame]]

So if the build machines are all running 10.5/Xcode 3.1, then the request is simply to update the SDK version in the mozconfig we're using.

No, this doesn't have signoff from anyone. I filed this hoping that the appropriate person would consider it....

Note that there's (at least) one known issue with running 10.5-created builds on 10.4, see bug 423691. But it looks like we have a possible workaround in that bug which we could use to maintain compatibility, even if no more elegant solution is found for now.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Ok, this belongs in Core::Build Config then.

Comment 4

[cmtalbert]

One thing to think about here is that all our automated test machines are 10.5, so if this does cause any issues, we aren't going to see them.

Comment 5

[(not currently active) Ted Mielczarek]

I think this is Josh's call to make.

Comment 6

[Josh Aas]

I don't think the 10.5 SDK upgrade alone is worth it for 1.9.2. 

Risks factors:
1. already pretty late for an SDK switch
2. switching to an SDK higher than the minimum supported OS
3. shipping a new text back-end
4. shipping 2 text back-ends

We'd be taking on that risk for what I understand to be a pretty small overall performance improvement with little testing for cases where performance might regress.

It would almost certainly be worth upgrading the SDK if we also got a new compiler (gcc-4.2) and a new minimum OS (10.5) because that would bring significant known performance improvements and remove risk factors 2 and 4.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Josh: dumb question; but does this mean you also don't think we should move mozilla-1.9.2 to the 10.6 SDK?

Comment 8

[Josh Aas]

I think we should always use the SDK for the lowest OS we support unless we have a really good reason for doing something else. I can't think of any reason why we'd use the 10.6 SDK for any binary that supports 10.5.

Comment 9

[(not currently active) Ted Mielczarek]

WONTFIX? We switched m-c (1.9.3) to the 10.5 SDK in bug 501436, and it doesn't seem worth trying to support targeting a lower version of the OS than the SDK we're building with. Too many fiddly issues to get right there, in my experience.

Comment 10

[Jonathan Kew [:jfkthame]]

Yes, as we're apparently abandoning 10.4 on trunk, this becomes irrelevant. It was a possible alternative to allow us to begin moving forward with some 10.5 features if we weren't ready to completely cut off 10.4 support yet, but it seems we've taken that step.