<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>I understand what you’re asking, and the part that won’t work (in the *general* case) is configuring with two different compilers and two different CMake generators in the *same* directory.</div><div> </div><div>If you configure/generate in two separate directories, and then merge the resulting generated project files into a set of project files that have multiple architecture references in them, that would be more likely to succeed than what you suggest. That would be a whole separate bundle of work, with its own set of challenges.</div><div> </div><div>Either way, what you’re asking for is a significant chunk of re-work. It is not as simple as it sounds like you imagine it to be...</div><div> </div><div>The CMakeCache.txt, configure_file output in the build tree, generated files, and more (all of which may have differences in them due to switching from 32-bit to 64-bit compilers) either have to be avoided or accounted for, in order to make a scheme like this work. It’s possible, but it does not exist right now, and the work required to make it happen is fairly significant (i.e., I don’t see how you could do it with less than *months* of effort).</div><div> </div><div>Like I said, a noble and worth idea, but quite some work to see it through.</div><div> </div><div>Good discussion. <span style='font-family: "Segoe UI Symbol","Apple Color Emoji";' data-externalstyle="false">😊</span></div><div> </div><div> </div><div>Cheers,</div><div>David</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 10:43 AM<br> <strong>To:</strong> cmake@cmake.org<br> <strong>Subject:</strong> Re: [CMake] Cmake and Visual Studio platforms<br> </div> <div> </div>Hi David!<br><br>We either misunderstand each other, or my knowledge of CMake is too limited,<br>but let me try to clarify this one last time, and if you still say it cannot<br>work, I'll leave it at that:<br><br>1) I configure my project using Win32 with output dir A. In this directory<br>every intermediate test and result is cached that were needed to configure<br>my project.<br><br>2) I press generate, and the actual project and solution files are assembled<br>in a temp directory (or in memory).<br><br>2.5) NEW Prior to writing data on disk, CMake checks whether there are<br>project/solution files with the name that it wishes to create. Sees that the<br>target dir A is empty, and ultimately they are written to disk.<br><br>3) After this I close my previous session of CMake, open a new one with the<br>x64 compiler toolset and try to configure my project using the Win64<br>generator to the same dir A. CMake sees that all cached variables are saved<br>with a different compiler, and as you say, they become invalidated. So far,<br>so good, I do not care about cached variables being invalidated, because my<br>generated Win32 project file is already complete and written to disk.<br><br>4) I press generate, again in a temp dir (or in memory) my x64 project and<br>solution files are assembled, and are ready to be written to disk.<br><br>4.5) NEW CMake checks whether there are project/solution files with the name<br>that it wishes to create. It sees that there are files already inside dir A,<br>opens them, checks the platform and if it is the same it is actually trying<br>to write, it will overwrite normally. If the platform found on the disk is<br>different than the one it tries to write, it makes the aforementioned<br>insertions into the xml code and tadaaaa: I got my multi-platform VS<br>solution.<br><br>As far as I see no great refactoring is needed to be done in CMake. The only<br>part where this could fail, is that using a new generator (and compiler) in<br>the same dir A that already contains generated project files is wiped right<br>at the beginning of the process. Since cached variables outlive a certain<br>configuration/generation process, I suspect that the generated Make/IDE<br>files do too, and they are only overwritten in this final step. (Tested:<br>true)<br><br>I have not seen CMake source code ever in my life, but I know that the<br>previous Make/IDE files remain the same until the very last step of<br>"Generate" when they are overwritten. This very last part would need to be<br>altered in the sole case of VS project generators.<br><br>If CMake developers say that the code is simply not structured like that, or<br>it is too much work to rewrite these parts (and a few others that might<br>depend on it), then I leave this subject be and not bother again with it.<br><br><br><br>--<br>View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583442.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>