The 32 vs 64 bit switch based on pointer size is not sufficient. To be 100% correct you shall be able to differentiate between x86_64 and IA-64 (However I think it's quite rare case). And to me personally condition with target architecture looks better than CMAKE_CL_64 or checking the size of pointer.<br>
<br>I think the "... Win64" generator is a bit confusing because what it actually does - is cross-compilation however cross-compilation requires more variables to be set properly.<br><br>I also need an advice on how to deal with package configs. They've proven to be very convenient but how to differentiate when you have single header location and 32- and 64-bit libraries?<br>
<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 9:37 PM, John Drescher <span dir="ltr"><<a href="mailto:drescherjm@gmail.com" target="_blank">drescherjm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Having CMAKE_SYSTEM_PROCESSOR be "x86" for a 64-bit build is very inconvenient when detecting machine-dependent compiler flags, constructing directory names for outputs based on configuration, configuring third party search directories, etc. It's always possible to work around (among other things, one can consult the generator string for Visual Studio builds, though not for MinGW builds) but that doesn't mean it shouldn't be better behaved - it's entirely reasonable to assume that CMAKE_SYSTEM_PROCESSOR should be the target processor for the build, especially so that you can have similar behavior on Windows, Linux, and Mac. Though as previously discussed I also have the opposite problem on Linux when compiling for 32-bit CPU on 64-bit OS.<br>
<br>
<br>
</div>I see. I have always compared the size of the pointer for this..<br>
<span class="HOEnZb"><font color="#888888"><br>
John<br>
</font></span></blockquote></div><br>