Closed Bug 674655 Opened 13 years ago Closed 12 years ago

Drop references to ppc, switch x86 to using the 10.6 sdk

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: espindola, Unassigned)

References

Details

Attachments

(1 file)

Drop references to ppc, switch x86 to using the 10.6 sdk
1.67 KB, patch
jaas
: review+
ted
: review+
Details | Diff | Splinter Review 
With these dependencies fixed, it is possible to build with the 10.6 sdk a binary that works on 10.5. We should do that to drop the dependency on the 10.5 sdk that is not included in newer versions of XCode.
Attachment #548881 - Flags: review?(catlee)
This bug would be more appropriate in Core::Build Config, reviewed by josh (Josh Aas) or bsmedberg.
Attachment #548881 - Flags: review?(catlee) → review?(joshmoz)
Component: Release Engineering → Build Config
Product: mozilla.org → Core
QA Contact: release → build-config
Target Milestone: --- → Future
Version: other → unspecified
For the record, we're still building PPC-compatible Firefoxes in TenFourFox-land. I can certainly back this out in our internal changesets, but I wanted to register the exception.
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

I'm fine with dropping PPC references but this changes the SDK for our i386 builds. Theoretically targeting 10.5 using the 10.6 SDK should be equivalent to using the 10.5 SDK but we've seen before that it is not. This makes me hesitant to mess with the SDK.
Do you want me to split the patch in ppc and x86 parts?

What problems have you had in the past building with the 10.6 sdk? In the tests I did the only problem I had was the libcrypto version, but that dependency was already dropped.

Once the builds are running on 10.6 machines (but still with the 10.5 sdk), I will do full try runs to see if there are any other problems.
The problems we had in the past had to do with 10.3/10.4/10.5 SDKs. I don't recall the exact issues but the lesson learned was that Apple doesn't maintain the target-OS macros meticulously enough to completely accurately simulate an earlier SDK.

After thinking about it a bit more I'm not necessarily against trying it again but I want to make sure it is acknowledged that this is a non-trivial build change. I'd also like an r+ from Ted before we do this.

Don't bother splitting the patch.
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Review of attachment 548881 [details] [diff] [review]:
-----------------------------------------------------------------

Before landing this please make sure that all of our i386 builds have "--enable-macos-target=10.5" set.
Attachment #548881 - Flags: review?(ted.mielczarek)
Attachment #548881 - Flags: review?(joshmoz)
Attachment #548881 - Flags: review+
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Might be best to add the "--enable-macos-target=10.5" stuff to "mozconfig.common" actually, in which case this patch will need to be modified.
Actually, that might be taken care of via a default in "configure.in".
good point, the configure default is 10.5. Would you prefer if I removed the

ac_add_app_options i386 --target=i386-apple-darwin$DARWIN_VERSION

line?

I will not commit until the dependencies are fixed and a full test run is done one the bots.
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #9)
> good point, the configure default is 10.5. Would you prefer if I removed the
> 
> ac_add_app_options i386 --target=i386-apple-darwin$DARWIN_VERSION
> 
> line?

I don't know enough about what that does and what the defaults are to make a decision on that.
Are we planning on moving our builds to a newer version of XCode? If not, why is this necessary? I don't see the problem with continuing to use the 10.5 SDK for our 10.5 builds until such point as we need to move to building on Lion.
What I am trying to avoid is having to build with 2 different XCode versions. There are XCode versions that have SDKs for 10.5 and 10.6 and others that have it for 10.6 and 10.7.

Moving the 10.5 build to use the 10.6 sdk would allow us to move to an XCode with the 10.6 and 10.7 sdks and still support 10.5, 10.6 and 10.7 (including features that use new APIs if they can be checked at runtime).
I was chatting with some chrome guys, and what they did is forward declare all the 10.7 APIs that they want.

The argument against using a new a new SDK was that it would make it easy for people to check in code that would depend on 10.6 only functions.

It is probably still a good idea to fix 674647, and drop the references to ppc, but I am not so sure about this one. I is probably up the devs using the new APIs, what do you prefer: having all new apis handy or the safety that you are not creating a 10.6 dependency accidentally?
Comment on attachment 548881 [details] [diff] [review]
Drop references to ppc, switch x86 to using the 10.6 sdk

Review of attachment 548881 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine. Do you want to just merge this back into build/macosx/universal/mozconfig? The only reason I split it out into .common was to support both ppc/i386 and i386/x86_64 universal builds during the transition period.
Attachment #548881 - Flags: review?(ted.mielczarek) → review+
I can do it. Note that the dependency on 674647 is a hard one. We cannot check this in while some build bots are running with 10.5 with no 10.6 SDK.
OS: Linux → Mac OS X
(In reply to Ted Mielczarek [:ted, :luser] from comment #11)
> Are we planning on moving our builds to a newer version of XCode? If not,
> why is this necessary? I don't see the problem with continuing to use the
> 10.5 SDK for our 10.5 builds until such point as we need to move to building
> on Lion.

We're actually coming up to a point where this may be necessary. 

Early in 2012, we'll be moving out of one of our current colos (sjc1) where our current Mac build machines (a mixture of old minis and xserves) reside. The new colo (scl3) will not support the old minis due to the cold aisle technology in use. The xserves could be moved, but on their own, they would not provide sufficient build capacity, and many of the xserves have already started to fail since they are reaching the end of their natural lifetime.

We're faced with buying new hardware to replace these builders, and new hardware in this case means minis running 10.7. Sometime in the very near future (January) we'll need to be able to build on Lion for whatever OS targets we still consider relevant. If we can still support 10.5 with only the 10.6 SDK, that would be ideal.

Has there been discussion anywhere about when we would stop officially supporting 10.5 altogether?
> Has there been discussion anywhere about when we would stop
> officially supporting 10.5 altogether?

I'm not aware of any public discussion.

JP, I remember discussing with you the possibility coordinating the
dropping of support for OS X 10.5 with other changes, including
dropping support for older OS versions on other platforms.  But I
can't find any record of it -- I think we must have been talking on
Skype.  Have these discussions gone any	further?  Are they now public?

Josh, do you know anything about this?
Chris, do you know anything about what's discussed in comment #17?
(In reply to Steven Michaud from comment #17)
> > Has there been discussion anywhere about when we would stop
> > officially supporting 10.5 altogether?
> 
> I'm not aware of any public discussion.
> 
> JP, I remember discussing with you the possibility coordinating the
> dropping of support for OS X 10.5 with other changes, including
> dropping support for older OS versions on other platforms.  But I
> can't find any record of it -- I think we must have been talking on
> Skype.  Have these discussions gone any	further?  Are they now public?

The discussions have not happened.  XP prior to SP2 and Windows ME I believe are also candidates for dropping soon.
We are coming to a decision point with respect to the datacenter move -- we will bear significant expense to move ancient hardware to a new datacenter if we don't have (or know we will have soon) the capability to build for 10.5 on 10.7 by the end of January.  The expense is the worse because it's good money after bad -- these ancient minis will die eventually, hopefully after we stop needing them.

Is it possible to finish this bug in the next 3.5 weeks?
hopefully you mean 10.6, right?

It should now be possible to build to 10.5 from 10.6 (module releng work), but I have not tested 10.7 -> 10.5 in a long time and it requires using the 10.6 sdk, which should work, but requires more testing.
Let me remind everyone that we need user testing on OS X 10.5 of builds that have been made with the 10.6 SDK.

I suggest we start very soon to build trunk nightlies (the 32-bit parts of them) using the 10.6 SDK.  This won't give us a whole lot of testing, but at least it will be a start.
I think it is easier to switch the build to the 10.6 machines first (but still using  the 10.5 sdk) and then switch the SDK, but I will let someone from releng confirm.
I actually do mean 10.7.  Specifically, I would like to do *all* mac builds (debug, opt, 32, 64 .. ALL) on 10.7 systems, as we can no longer purchase systems that will run 10.6 or 10.5, and we are losing the ability to house our older Apple hardware (which is slowly dying anyway) as coop described in comment 16.  This isn't quite a sky-is-falling moment: as I mentioned in comment 20, we have a contingency plan, but it's expensive and wasteful and only buys us time on the build-on-10.7 project.

From my understanding, this bug is specifically about teaching the build system to target 10.5 using the 10.6 SDK.  That is a component of building on 10.7, but building on 10.7 also requires building with a version of XCode that is compatible with 10.7.  AIUI that means 4.1, as opposed to the XCode 3 that's available on current 10.6 builders.

Should I open a new bug for the second part?

Is this at all practical in this timescale?

(P.S. the silver lining is that this applies only to build systems - we will have 10.5, 10.6, and 10.7 testers for quite a while, as they are in another datacenter).
> Should I open a new bug for the second part?

I went with "yes": bug 715397
On bug 698827 we're working on the last steps to run the 10.5 leak builds on the 10.6 machines.
After bug 674647 got fixed we only need darwin9 slaves for:
* mozilla-aurora
* mozilla-beta
* mozilla-release
* mozilla-1.9.2 (aka Firefox 3.6 which is to be EOL on Apr. 24th)

We're going to backport that work to mozilla-aurora on bug 674647
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #27)
> We're going to backport that work to mozilla-aurora on bug 674647

That is bug 719499
No longer blocks: 715337
should have removed the blocker bug # also - this no longer blocks scl3
No longer blocks: 715397
This has been fixed some time ago, but I forgot to close the bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: