[CMake] Recommended Multilib Build Approach?

[Gregory Peele ARA/CFD]

From: Alexander Neundorf [mailto:a.neundorf-work at gmx.net] 
Sent: Saturday, July 28, 2012 11:48 AM
To: cmake at cmake.org
Cc: Gregory Peele ARA/CFD
Subject: Re: [CMake] Recommended Multilib Build Approach?

On Thursday 21 June 2012, Gregory Peele ARA/CFD wrote:
>> Hi all,
>> 
>> I want to be able to build 32-bit and 64-bit from the same GCC multilib
>> install (currently for MinGW-w64, though this also applies for Linux/Mac
>> GCC and LLVM). To clarify, I want to be able to do two completely
>> separate builds in separate binary dirs - building fat binaries from
>> multiple architectures in the same binary dir is a separate problem I'm
>> also interested in for Android, but I'm not worrying about that yet.
>> 
>> What is the "proper" approach to building the non-default arch in a
>> multilib setup? Obviously using CMake as-is will build the default arch
>> just fine.
> I think there are no recommendations yet. I'm not aware that somebody else already tried to do this.
> Can the executables built for the non-default architecture be executed on the hopst where you are building ?
> If so, there should be a way :-)
> If not, this sounds like somewhat like crosscompiling.
> Alex

I haven't explored the topic any further since posting.  On a multilib system, all multilib architectures are "native" to the host and can be executed.  Basically the problem I wanted to solve was getting the x86-64 GCC or LLVM compiler to produce 32-bit x86 code in an easy and non-intrusive way.

Right now I'm forcibly adding the "-m32" flags to all relevant CMake variables within my top-level CMake script if CMAKE_SYSTEM_PROCESSOR is set to x86 or i686, and conversely the "-m64" flags if set to x86-64 or AMD64.  It seems like there should be a less intrusive way of doing it, and I'm not sure if this skews some early compiler/platform tests prior to me overriding the flags.  Visual Studio doesn't have this issue since the 32-bit and 64-bit builds are entirely separate CMake generators - a strange decision, in my opinion, but easy enough to work with.

Greg