ppc/x86 universal Mac packages will need attention where TARGET_XPCOM_ABI is used. Some users of TARGET_XPCOM_ABI (update) need to know whether the running application is within a universal binary or not.
As discussed on #camino, there are a couple issues here: 1) for software update, the ABI doesn't actually identify the build being shipped: we're going to need another "update identifier". I'm going to morph this bug into the update issue. 2) for extension manager, the ABI value appears to be correct, but we have a problem that the "nsExtensionManager.js" file is preprocessed to contain the ABI value directly, instead of reading it from nsIXULRuntime. I'm going to file a separate bug about this.
Except of course that the update code is implemented in JS...
I meant that we could XPCOMify the utility function I wrote for that bug.
New patch on bug 323657, attachment 209377 [details] [diff] [review], lets you get universalness through an XPCOM interface.
We should have something ready on this for the initial Universal release.
Renominate when you've got a working patch.
The isUniversalBinary attribute from bug 323657 has landed on the trunk.
Created attachment 212233 [details] [diff] [review] Darwin_gcc3-Universal, rev. 1
Comment on attachment 212233 [details] [diff] [review] Darwin_gcc3-Universal, rev. 1 >Index: toolkit/mozapps/update/src/nsUpdateService.js.in ... >+#if 0 Will this screw up line numbers in JS errors reported to the JS console? If not, then why don't we fix the preprocessor to strip comments?
.js files automatically have //@line information added by the XUL preprocessor so reported line numbers are correct And auto-stripping comments is very hard to do correctly; it would basically involve a full JS parser/tokenizer.
Comment on attachment 212233 [details] [diff] [review] Darwin_gcc3-Universal, rev. 1 This'll obviously need some minor server-side work too.
I don't think it will be minor, but it will be almost entirely on the tinderbox. Tt can/should be done at the same time the tinderbox automation of universals is done.
Created attachment 212240 [details] [diff] [review] Darwin_Universal-gcc3
Comment on attachment 212240 [details] [diff] [review] Darwin_Universal-gcc3 Looks good, but I think it might be wise to stick a LOG() statement in the catch block indicating that the ABI is unknown. Then at least users could figure out why their Update Service was effectively dead. What do you think? r=me, with or without the log message
Created attachment 212248 [details] [diff] [review] As checked in Needed for branches to implement mac universal binaries, should be low-risk.
Comment on attachment 212248 [details] [diff] [review] As checked in approved for 1.8.0 branch, a=dveditz
Fixed on trunk, 1.8, 1.8.0