<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style></head><body><div data-externalstyle="false" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:16px;"><div>This is a noble and worthy idea. Unfortunately, it just won’t work, given the way that CMake has historically evolved, and the assumptions made by most folks writing CMakeLists files.</div><div> </div><div>Here are some facts:</div><div> </div><div>The C and C++ compilers are usually determined very early on in the configure process, and cached so that a build tree is irrevocably bound to that single compiler.</div><div> </div><div>EVERY SUBSEQUENT TEST done at configure time that uses the compiler to compute its results is also cached, and tied to that single compiler. Changing the compiler, or having multiple compilers, makes all of those results INVALID.</div><div> </div><div>There is code like “if(CMAKE_SIZEOF_VOID_P EQUAL 8) then (do something x64-ish...)” in many CMakeLists.txt files that depends on a single compiler (either 32-bit *or* 64-bit) being used.</div><div> </div><div data-focusfrompointer="true">These facts conspire against your idea, and do not allow CMake to generate a solution that contains both architectures, UNLESS you are willing to re-write existing CMakeLists files for projects that need this such that they do not rely on the compiler results at configure/generate time. (And do tons and tons of re-work of CMake code to enable the possibility...) For any project that does any sort of try_compile operation, this cannot work when multiple compilers are involved. Unless you redesign try_compile to do multiple tries, and yield multiple results.</div><div> </div><div>Hope this helps to explain things.</div><div> </div><div>Use separate build trees, use single configuration generators in each, and build multiple times. That’s the CMake way to do what you want.</div><div> </div><div>Anything else is a completely major re-write, and will not work with 95%+ of the existing CMakeLists files in the world.</div><div> </div><div> </div><div>Unfortunate, but true,</div><div>David C.</div><div> </div><div> </div><div data-signatureblock="true"> </div> <div style="border-top-color: rgb(225, 225, 225); border-top-width: 1px; border-top-style: solid;"> <strong>From:</strong> Meteorhead<br> <strong>Sent:</strong> March 1, 2013 5:28 AM<br> <strong>To:</strong> cmake@cmake.org<br> <strong>Subject:</strong> Re: [CMake] Cmake and Visual Studio platforms<br> </div> <div> </div>I understand why CMake cannot resolve the issue in a single call to<br>configure. However...<br><br>how tricky/hard/impossible would it be to alter/rape the generate stage of<br>CMake to handle this issue? <br><br>Let's say I wanted to create a Win32 and an x64 platform inside a<br>solution/project. Then I would start a VS command prompt for the native 64<br>and 32 bit compilers. I'd start a CMake GUI from both (or use the command<br>line, whatever) and configure once a 32-bit and once a 64-bit solution. The<br>tricky part comes here: both CMake instances have their output directory set<br>to the same directory.<br><br>I could image the generate stage (or even later internally just when writing<br>the output files), that when I generate let's say the 32-bit first, it sees<br>an empty directory, creates all neccessary files, and it's done. When I hit<br>generate the second time on the 64-bit configuration, it finds solution<br>files with Win32 set as platform. Instead of overwriting all the project and<br>solution files, it could insert into the xml code it's own x64 platform and<br>leave the others as it is. This way both platforms would compile and link<br>the proper libraries and dependencies.<br><br>Having met CMake as not an end-user only 3 weeks ago, I have little<br>knowledge of the intimacies of the configuration cache for example, so I<br>could imagine that having two different configuration set onto the same<br>output directory could cause mishaps, but that is why I ask the black-belt<br>people here.<br><br>I have not used other IDEs throroughly, but I can image CodeBlocks or XCode<br>has got their own equivalent (or maybe not) of platforms beside regular<br>build targets. Could this setup of configurate/generate serve as a solution<br>to our problem? Is there hope of it being implemented? Or are there<br>conceptual errors along the way that I have not come to realise?<br><br>(I could image changing the behavior of "shoot first, ask later", namely do<br>not check anything, just overwrite whatever we find in the target dir, could<br>be misleading in the sense that one would expect such behavior from all<br>generators, but instead the VS generator parses the found solution/project<br>files, and inserts code into it if the platforms differ, rather than<br>overwriting the entire thing. I believe these behavioral differences could<br>be overlooked, if one could make multi-platform solution files.)<br><br>Ideas? Suggestions? Flame?<br><br><br><br>--<br>View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583436.html<br>Sent from the CMake mailing list archive at Nabble.com.<br>--<br><br>Powered by www.kitware.com<br><br>Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<br><br>Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<br><br>Follow this link to subscribe/unsubscribe:<br>http://www.cmake.org/mailman/listinfo/cmake<br></div></body></html>