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.
