Re: [CMake] Cmake and Visual Studio platforms
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. 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. 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... 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). Like I said, a noble and worth idea, but quite some work to see it through. Good discussion. 😊 Cheers, David From: Meteorhead Sent: March 1, 2013 10:43 AM To: cmake@cmake.org Subject: Re: [CMake] Cmake and Visual Studio platforms Hi David! We either misunderstand each other, or my knowledge of CMake is too limited, but let me try to clarify this one last time, and if you still say it cannot work, I'll leave it at that: 1) I configure my project using Win32 with output dir A. In this directory every intermediate test and result is cached that were needed to configure my project. 2) I press generate, and the actual project and solution files are assembled in a temp directory (or in memory). 2.5) NEW Prior to writing data on disk, CMake checks whether there are project/solution files with the name that it wishes to create. Sees that the target dir A is empty, and ultimately they are written to disk. 3) After this I close my previous session of CMake, open a new one with the x64 compiler toolset and try to configure my project using the Win64 generator to the same dir A. CMake sees that all cached variables are saved with a different compiler, and as you say, they become invalidated. So far, so good, I do not care about cached variables being invalidated, because my generated Win32 project file is already complete and written to disk. 4) I press generate, again in a temp dir (or in memory) my x64 project and solution files are assembled, and are ready to be written to disk. 4.5) NEW CMake checks whether there are project/solution files with the name that it wishes to create. It sees that there are files already inside dir A, opens them, checks the platform and if it is the same it is actually trying to write, it will overwrite normally. If the platform found on the disk is different than the one it tries to write, it makes the aforementioned insertions into the xml code and tad: I got my multi-platform VS solution. As far as I see no great refactoring is needed to be done in CMake. The only part where this could fail, is that using a new generator (and compiler) in the same dir A that already contains generated project files is wiped right at the beginning of the process. Since cached variables outlive a certain configuration/generation process, I suspect that the generated Make/IDE files do too, and they are only overwritten in this final step. (Tested: true) I have not seen CMake source code ever in my life, but I know that the previous Make/IDE files remain the same until the very last step of "Generate" when they are overwritten. This very last part would need to be altered in the sole case of VS project generators. If CMake developers say that the code is simply not structured like that, or it is too much work to rewrite these parts (and a few others that might depend on it), then I leave this subject be and not bother again with it. -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583442.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
On Fri, Mar 1, 2013 at 10:52 AM, John Drescher wrote: >> If CMake developers say that the code is simply not structured like that, or >> it is too much work to rewrite these parts (and a few others that might >> depend on it), then I leave this subject be and not bother again with it. > > David led the CMake development for years. http://www.kitware.com/blog/home/user/9 John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
> If CMake developers say that the code is simply not structured like that, or > it is too much work to rewrite these parts (and a few others that might > depend on it), then I leave this subject be and not bother again with it. David led the CMake development for years. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
Hi David! We either misunderstand each other, or my knowledge of CMake is too limited, but let me try to clarify this one last time, and if you still say it cannot work, I'll leave it at that: 1) I configure my project using Win32 with output dir A. In this directory every intermediate test and result is cached that were needed to configure my project. 2) I press generate, and the actual project and solution files are assembled in a temp directory (or in memory). 2.5) NEW Prior to writing data on disk, CMake checks whether there are project/solution files with the name that it wishes to create. Sees that the target dir A is empty, and ultimately they are written to disk. 3) After this I close my previous session of CMake, open a new one with the x64 compiler toolset and try to configure my project using the Win64 generator to the same dir A. CMake sees that all cached variables are saved with a different compiler, and as you say, they become invalidated. So far, so good, I do not care about cached variables being invalidated, because my generated Win32 project file is already complete and written to disk. 4) I press generate, again in a temp dir (or in memory) my x64 project and solution files are assembled, and are ready to be written to disk. 4.5) NEW CMake checks whether there are project/solution files with the name that it wishes to create. It sees that there are files already inside dir A, opens them, checks the platform and if it is the same it is actually trying to write, it will overwrite normally. If the platform found on the disk is different than the one it tries to write, it makes the aforementioned insertions into the xml code and tad: I got my multi-platform VS solution. As far as I see no great refactoring is needed to be done in CMake. The only part where this could fail, is that using a new generator (and compiler) in the same dir A that already contains generated project files is wiped right at the beginning of the process. Since cached variables outlive a certain configuration/generation process, I suspect that the generated Make/IDE files do too, and they are only overwritten in this final step. (Tested: true) I have not seen CMake source code ever in my life, but I know that the previous Make/IDE files remain the same until the very last step of "Generate" when they are overwritten. This very last part would need to be altered in the sole case of VS project generators. If CMake developers say that the code is simply not structured like that, or it is too much work to rewrite these parts (and a few others that might depend on it), then I leave this subject be and not bother again with it. -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583442.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
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. Here are some facts: 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. 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. 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. 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. Hope this helps to explain things. Use separate build trees, use single configuration generators in each, and build multiple times. That’s the CMake way to do what you want. Anything else is a completely major re-write, and will not work with 95%+ of the existing CMakeLists files in the world. Unfortunate, but true, David C. From: Meteorhead Sent: March 1, 2013 5:28 AM To: cmake@cmake.org Subject: Re: [CMake] Cmake and Visual Studio platforms I understand why CMake cannot resolve the issue in a single call to configure. However... how tricky/hard/impossible would it be to alter/rape the generate stage of CMake to handle this issue? Let's say I wanted to create a Win32 and an x64 platform inside a solution/project. Then I would start a VS command prompt for the native 64 and 32 bit compilers. I'd start a CMake GUI from both (or use the command line, whatever) and configure once a 32-bit and once a 64-bit solution. The tricky part comes here: both CMake instances have their output directory set to the same directory. I could image the generate stage (or even later internally just when writing the output files), that when I generate let's say the 32-bit first, it sees an empty directory, creates all neccessary files, and it's done. When I hit generate the second time on the 64-bit configuration, it finds solution files with Win32 set as platform. Instead of overwriting all the project and solution files, it could insert into the xml code it's own x64 platform and leave the others as it is. This way both platforms would compile and link the proper libraries and dependencies. Having met CMake as not an end-user only 3 weeks ago, I have little knowledge of the intimacies of the configuration cache for example, so I could imagine that having two different configuration set onto the same output directory could cause mishaps, but that is why I ask the black-belt people here. I have not used other IDEs throroughly, but I can image CodeBlocks or XCode has got their own equivalent (or maybe not) of platforms beside regular build targets. Could this setup of configurate/generate serve as a solution to our problem? Is there hope of it being implemented? Or are there conceptual errors along the way that I have not come to realise? (I could image changing the behavior of "shoot first, ask later", namely do not check anything, just overwrite whatever we find in the target dir, could be misleading in the sense that one would expect such behavior from all generators, but instead the VS generator parses the found solution/project files, and inserts code into it if the platforms differ, rather than overwriting the entire thing. I believe these behavioral differences could be overlooked, if one could make multi-platform solution files.) Ideas? Suggestions? Flame? -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583436.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this
Re: [CMake] Cmake and Visual Studio platforms
I understand why CMake cannot resolve the issue in a single call to configure. However... how tricky/hard/impossible would it be to alter/rape the generate stage of CMake to handle this issue? Let's say I wanted to create a Win32 and an x64 platform inside a solution/project. Then I would start a VS command prompt for the native 64 and 32 bit compilers. I'd start a CMake GUI from both (or use the command line, whatever) and configure once a 32-bit and once a 64-bit solution. The tricky part comes here: both CMake instances have their output directory set to the same directory. I could image the generate stage (or even later internally just when writing the output files), that when I generate let's say the 32-bit first, it sees an empty directory, creates all neccessary files, and it's done. When I hit generate the second time on the 64-bit configuration, it finds solution files with Win32 set as platform. Instead of overwriting all the project and solution files, it could insert into the xml code it's own x64 platform and leave the others as it is. This way both platforms would compile and link the proper libraries and dependencies. Having met CMake as not an end-user only 3 weeks ago, I have little knowledge of the intimacies of the configuration cache for example, so I could imagine that having two different configuration set onto the same output directory could cause mishaps, but that is why I ask the black-belt people here. I have not used other IDEs throroughly, but I can image CodeBlocks or XCode has got their own equivalent (or maybe not) of platforms beside regular build targets. Could this setup of configurate/generate serve as a solution to our problem? Is there hope of it being implemented? Or are there conceptual errors along the way that I have not come to realise? (I could image changing the behavior of "shoot first, ask later", namely do not check anything, just overwrite whatever we find in the target dir, could be misleading in the sense that one would expect such behavior from all generators, but instead the VS generator parses the found solution/project files, and inserts code into it if the platforms differ, rather than overwriting the entire thing. I believe these behavioral differences could be overlooked, if one could make multi-platform solution files.) Ideas? Suggestions? Flame? -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415p7583436.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
On Thu, Feb 28, 2013 at 6:31 AM, John Drescher wrote: >> There are multiple posts in multiple forums asking this question, so >> naturally there is public need for this feature. How come CMake never aimed >> at creating a solution for this? I suspect there is some great design issue >> that prevents implementing it in CMake. There are several platform and >> generator specific options already inside CMake, why can't this be another >> one? >> > I believe the current method of forcing the developer to use different > build trees for 64bit and 32bit works very well. I have used this for > almost 5 years now of development under Visual Studio 2005 to 2012. Also there are reasons why this will not work in the current design. Outside of the few CMAKE variables that are set for the compiler that would be wrong the biggest problem I believe would be libraries. You can not link a x64 library with a 32 bit program so CMake would have to track what libraries were x64 versus 32bit which may seem like just adding additional configurations over Release,Debug ... would solve but that will not work with the way finders work. Also I do not believe CMake supports this configuration on any other platform. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake and Visual Studio platforms
> There are multiple posts in multiple forums asking this question, so > naturally there is public need for this feature. How come CMake never aimed > at creating a solution for this? I suspect there is some great design issue > that prevents implementing it in CMake. There are several platform and > generator specific options already inside CMake, why can't this be another > one? > I believe the current method of forcing the developer to use different build trees for 64bit and 32bit works very well. I have used this for almost 5 years now of development under Visual Studio 2005 to 2012. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cmake and Visual Studio platforms
Hi! I've been learning CMake for the past 2-3 weeks now, expanding my project feature by feature through making a tutorial for fellow scientists, and there is one big question that people (such as myself and others) ask coming from the Windows side of development: Why can't CMake create platforms inside a generated project? The question is not whether CMake can do it or not. I have found enough topics stating that it cannot. I understand that MSVC is the only compiler that has seperate executables for the 32-bit and the 64-bit compiler, which all other civilized compilers handle via a command line architecture flag. Clearly it is inside VS that handles whether it calls the 32-bit cl.exe, or the 64-bit one. And the interesting part comes here: There are multiple posts in multiple forums asking this question, so naturally there is public need for this feature. How come CMake never aimed at creating a solution for this? I suspect there is some great design issue that prevents implementing it in CMake. There are several platform and generator specific options already inside CMake, why can't this be another one? -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-and-Visual-Studio-platforms-tp7583415.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
