Detect 32-bit/64-bit correctly based on CFLAGS

[ryandesign]

The user might invoke cmake with CFLAGS containing "-m32" or (on OS X) "-arch i386" while on a 64-bit machine to indicate that it should build for 32-bit instead.

[tresf]

Thanks Ryan. I assume this is to fix #2044?

FYI, GCC seems to believe this is undesirable via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52096 so I'm not sure if this will benefit other platforms (using GCC). I'll leave this open for comments for a few days prior to merging.

[ryandesign]

This does not address #2044.

I see; I only checked with clang, not gcc, but I see now that gcc indeed does not honor this. In that case, using -dumpmachine is probably not the correct way to detect bitness.

Ideally, you would not attempt to detect bitness at all in cmake, and would rely instead on preprocessor defines in your source code (for example, using #ifdef __LP64__). That would, assuming #2044 and any other 32-bit-specific bugs I find are resolved, allow building a universal binary on OS X in a single run.

[tresf]

allow building a universal binary on OS X in a single run.

Perhaps you can shed some light on this topic, because I reached out to MacPorts in regards to building for older platforms without much help via: #1270 (comment)

Furthermore, we use Travis-CI to create our Win32 binaries and we'd love to use a similar technique for the DMGs, but we lack the expertise to do so. :)

-Tres

[ryandesign]

In Apple terminology, a universal binary is one built for multiple architectures. This facility was introduced in 2005 when Apple first started using Intel processors in Macs instead of PowerPC processors, and the point was to allow a developer to distribute a single program that would work on any Mac regardless of its processor. At that time, "universal" typically meant a binary built for both 32-bit PowerPC and 32-bit Intel, though it is possible to include even more architectures than that, such as 64-bit PowerPC and 64-bit Intel. Since Mac OS X 10.6 and later run only on Intel Macs, these days a universal binary typically contains only 32-bit Intel and 64-bit Intel parts.

When it comes to software compiled from the command line, ideally a universal binary is produced by setting the environment variables CFLAGS, CXXFLAGS and LDFLAGS so that they contain -arch i386 -arch x86_64, and then invoking the configuration system (cmake in your case) a single time, followed by building the code (e.g. by running make) a single time, which produces binaries built for both architectures, which can then be installed (e.g. by running make install). However, if the configuration system attempts to detect the bitness (or endianness), this will not work properly, and a more complicated build must be performed: CFLAGS, CXXFLAGS and LDFLAGS must be set to include only -arch x86_64, then the configuration system is invoked, then the build is run. Then, in a separate copy of the source (or, if building in an out-of-source directory, in a separate out-of-source directory), the process is repeated with only -arch i386 in the environment variables. Finally, for each binary that will be installed, the lipo program is used to combine the separate architecture files into a single file. MacPorts supports both of these universal building strategies, but the more complicated process has numerous disadvantages so we prefer to avoid it if possible.

If lmms does not support building for 32-bit Intel on OS X (and I assume it does not support PowerPC), then it's a moot point.

The comment you referred me to in the other ticket seemed to be talking about building the program on a newer version of OS X while still letting it run on an older version of OS X. That's an unrelated concept. It is supposed to be possible to do that, by specifying the correct OS X SDK and the correct MACOSX_DEPLOYMENT_TARGET, which would of course need to be done not just for lmms but for every non-system library it uses as well. There are two settings that can be set in the macports.conf file to influence how these are set—macosx_sdk_version and macosx_deployment_target—however not all ports support it because most MacPorts developers and users do not use it so it is not well tested. For this reason the options are not mentioned in macports.conf and are not discussed in our documentation. In addition, these settings are not considered when MacPorts checks if pre-compiled binaries are available, so the use of pre-compiled binaries must be disabled by setting buildfromsource always in macports.conf, and if you've already installed any ports when you change this setting, you'll want to reinstall them.

I'm aware of the existence of Travis-CI but am not familiar with it. The MacPorts project uses buildbot to automatically build its packages, but we build on the same OS X version the user will run on. (We have 5 buildbot instances, one each on Mac OS X 10.6, 10.7, 10.8, 10.9 and 10.10.) I'm not familiar with how we set that up, though I'm told it wasn't that difficult and I may be able to find more information about our setup for you if you want.

Requiring that the version of OS X the user runs matches the version of OS X we built the binaries on is a strategy that works for MacPorts but is not what users of standalone Mac software would expect. They would expect that they can download a single program which works on any supported version of OS X, so I'm glad you're wanting to do that. Simply running the build on the earliest supported OS X version, like you're currently doing by building on Lion, is one reasonable way to accomplish that, though I understand how it might be more convenient to be able to do it from a newer version of OS X.

[tresf]

Simply running the build on the earliest supported OS X version, like you're currently doing by building on Lion, is one reasonable way to accomplish that, though I understand how it might be more convenient to be able to do it from a newer version of OS X.

Thanks, I suppose we'll continue doing it this way then.

So back on topic, since we're already using -dumpmachine to detect the 32-bit and 64-bit build environments, this change makes logical sense. If it causes unexpected build issues for other platforms, we can investigate an alternative route. Merging.