Remove assumption that build and target machine are the same (ie support Mac OS Universal Binaries)
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
Apple is now selling Macs that use 2 kinds of CPUs: PPC and Intel. Both kinds will be out there for years to come. They have created something called a 'universal binary' which is basically a single executable file that has both PowerPC and Intel object code, and so runs natively on both types of Mac. Both PPC and Intel Macs can compile both PPC and Intel code.
Building something as universal is pretty easy, at least in the sense that it only takes a few parameters to gcc. Recent versions of cmake now also include functionality to build universal binaries.
On the other hand, building something as universal is pretty hard in the sense that you must be sure to write your code in a portable way. Specifically, one must not assume that the target platform is the same as the build platform.
vtk makes this assumption in many places. This bug is requesting that it stop. :) I realise that this is no small task. It will take time, but it is something that can be done bit by bit.
The first step, I believe, is to stop making this assumption in all new vtk code. Perhaps: a) adding it to the coding standards here <http://www.vtk.org/Wiki/VTK_Coding_Standards>? b) informing all vtk developers (at kitware at least)
The next step is to find where the assumption is already made and get rid of it.
One problem is CMake's TRY_RUN functionality, which vtk uses for at least two things. Ideally, all TRY_RUN steps should be avoided, because by their nature they assume the build and target machines are of the same type.
vtk uses TRY_RUN for:
-
endianess The PPC is big endian, the Intel is little. Building vtk tests the build machine's endianess and potentially defines VTK_WORDS_BIGENDIAN. This is no good for building universal binaries, as it will always be wrong half the time. I'm not sure what the solution is here. Some ideas: a) there are POSIX APIs to swap bytes: ntohl, htonl, ntohs, and htons. But do they exist on windows? I guess not. b) Apple's gcc and Intel's mac compiler automatically #define BIG_ENDIAN or LITTLE_ENDIAN. I've read that 'most modern Unix systems define the byte order in the sys/param.h include file'. Does Windows have a similar header? If so, VTK_WORDS_BIGENDIAN could be defined by comparing to existing defines in system headers. c) endianess could be determined at runtime, but this may not be acceptable for performance-critical code.
-
Type sizes building vtk checks the size of various types such as char, short, int, long, float, and double on the build machine. For the particular case of Mac Universal Binaries, the sizes of these types do not change between PPC and Intel. But one day they might, as 64 bit CPUs become more popular. One type that does change size between ppc and intel is 'bool', it is 8 bit on one and 32 bit on the other, but I do not see any VTK_SIZEOF_BOOL or similar.
Lots of what vtk does with this info looks like this:
// Template ID's must be 32-bits. See .cxx file for more information. #if VTK_SIZEOF_SHORT == 4 typedef unsigned short TemplateIDType; #elif VTK_SIZEOF_INT == 4 typedef unsigned int TemplateIDType; #elif VTK_SIZEOF_LONG == 4 typedef unsigned long TemplateIDType; #endif
This kind of thing could be easily replaced using the standard integer types in stdint.h, These types are part of the C99 standard, 7 years old now. Like so:
typedef uint32_t TemplateIDType;
Then TemplateIDType will be 32bits no matter which platform it's built on. For info on these types, see: <http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html>
Or are there compilers that vtk must support that still do not support stdint.h? If so, they could be special-cased.
- Other. :) I'm sure there are other issues as well, but I think the above is a starting point. And I want to file this bug sooner than later.