[Not sure if this is strictly dev-platform material; dev-planning might have been more appropriate in some respects.]
Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version, and then squash those together to produce a universal binary that runs on 32-bit or 64-bit systems, as appropriate. This method of building is somewhat wasteful, as we're building a decent chunk of stuff (chrome JS, etc.) that is architecture independent. When targeting OS X, native or cross, clang supports compiling for multiple architectures in a single pass. Being able to use this capability would likely speed up our TBPL OS X builds somewhat. (Slowdown in actual compilation would likely be compensated for by not having to build chrome jars twice, install headers twice, etc. etc.) However, a variety of issues block being able to do this, mostly related to a number of places the code where decisions are made based on whether configure thought we're compiling for a 32-bit or 64-bit architecture. I've started poking at some of these issues (bug 925167 and dependents if you're interested). But various people have pointed out that it only makes sense to devote resources to this if we're going to be keeping 32-bit OS X support alive for some time to come. Otherwise, we can just wait a short amount of time for 32-bit support to be dropped and these issues go away. How long do we intend to continue shipping a 32-bit Firefox binary on OS X? As I understand it, we're doing this solely for our OS X 10.6 users, as they are the only ones potentially running OS X on non-64-bit capable machines. -Nathan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
