Review OSX universal mode patch

[David Holmes]

On 12/05/2012 4:17 AM, Mike Swingler wrote:
> On May 10, 2012, at 5:34 PM, David Holmes wrote:
>
>> On 11/05/2012 6:06 AM, Henri Gomez wrote:
>>> Happy to see subject back to technical.
>>>
>>> If you take a closer look to patch, you'll see universal is enforced as ARCH.
>>
>> My concerns with the patch is the necessity of introducing these platform specific ifdefs into what is notionally shared code - yes there are already ifdefs in there but I still dislike seeing this. And I think the various "arch" variables are being misused in ways that ultimately lead to confusion - the OSX build shouldn't require a completely different understanding of the build system.
>
> But the OS X build system builds for multiple architectures fundamentally differently than any other toolchain on any other OS.

That's basically the problem. If you were defining the build for OSX 
alone it would likely have a completely different structure. As it is 
the existing single-architecture based build is not compatible with the 
notion of "universal" build.

> By doing multiple passes on the same file at the same time, the disk cache is most effectively utilized. By simply tacking on additional architecture flags to the CFLAGS, more architectures can be trivially introduced into legacy Makefile projects without wide sweeping changes across the whole project to build into different directories. This is why we introduced concept of the "universal" architecture for the directory names, which could mean "i386", "x64_64", or "i386+x86_64", depending on how you were building.
>
>> I was not familiar with the Universal build and to be honest it seems to be more of a hindrance than a help. If the build was done as two passes: 32-bit then 64-bit with a stage at the end to produce the universal binary, then bit-specific make variables could continue to work as they were intended - is that possible?
>
> It's possible, but not easy. Given that we have a solution that works in the here and now, an #ifdef is a small price to pay until the next major build system refactoring occurs.

This seems like a hack and I'm surprised there aren't other parts of the 
build that require similar hacks. We reach a point where the pretense 
that a file contains (mostly) platform independent code no longer holds 
and we should refactor into platform specific files.

Or we try to find mechanisms for expressing things in a way that don't 
require platform-specific code.

YMMV. This is only my opinion.

David
-----

>> I also think this should be taken to JDK8 first.
>
> Of course.
>
> Regards,
> Mike Swingler
> Apple Inc.
>