Re: [CMake] Changing the the current generator in CMake GUI
On 1/15/2016 7:19 PM, mozzis wrote: Well, CMAKE is the thing that is conflating this idea of a “generator” (which is clearly a concept in CMAKE’s own domain of “build configuration generator”) with the idea of “platform” or “architecture” (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It would be healthier if platform/arch were broken out as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools have this concept, but is (possibly) agnostic about how it is represented. I assume that it is not really possible to do so in the config files that drive CMAKE at present, only because I have never seen it done and did not find it when I went looking. Instead, that information is scattered across several files in the CMakeFiles folder. So, in CMake it currently supports one platform/arch at a time. This is because of support for system introspection (trycompile/tryrun). configurations. The resulting build time was cut by a factor of 5, plus it became much easier (for me anyways) to be able to do things like change the output file names based on platform, something I have so far found impossible to do with CMake. [Once again, it really has no concept of this.] I really can't believe the build was faster, that just does not sound possible. At the end of the day CMake gives VS a list of files and VS compiles them. If you want something really fast with VS, use the CMake ninja generator instead of VS and get builds that are significantly faster than VS IDE builds. I would like to see a real example of that which I can reproduce, because we could modify CMake to create a similar project file. The only thing that could improve build times that much is adding the /MP flag, but that can be done with CMake right now. (see my blog http://www.kitware.com/blog/home/post/434) CMake does have the ability to change output names based on configuration with target properties. However, the VS project files are not intended to be changed but only generated. The changes should all happen in the CMake input files or the next time you run CMake all the changes will be lost. CMake is not intended to create an IDE file that then can be changed/maintained on its own. It will be erased and overwritten as soon as there is any change in a CMake input file used to generate it. I would do the same thing for OpenCV, but it is ten times worse than HDF5 in this regard. For instance, apparently project files are modified /as part of the MSVS build process/, so that Visual Studio always complains about project files needing to be reloaded after a build. This is a recipe for mysterious bugs that you will never be able to fix. That sounds like something wrong in the OpenCV CMake files, it should not rerun cmake with each build. I have created/maintained multi-platform projects, and I find that the effort needed to produce efficient, readable makefiles for each platform is worth it. Once done, I can change the platform or the library type or similar parameters by changing one switch in each platform’s makefile. Plus there are fewer gotchas at runtime, as not querying the build environment for every build ensures more consistent behavior in the binaries I am going to distribute. If you have the time to maintain hand crafted makefiles/IDE project files then more power to you. Also, I assume that every developer on your project knows how to make changes to each platforms build files when they want to add a new source file or library. Thanks again to all for the comments on this thread. It is good to know that development continues on this tool. At some point, it may become more interesting for me. I really don't care if you use CMake or not. However, I want to make sure that I clear up any misconceptions that this thread may raise for others. To sum things up: - CMake is a cross platform build generator, the makefiles/IDE/build files that it generates are not meant to be human readable and especially human editable. The way to change what happens in the build has to be done by changing either the source CMakeLists.txt files or the CMakaCache.txt and not the build files. This is because the build files are written over each time CMake is run. - CMake is setup to make it easier for cross platform development with a team of developers that only needs to know how to add sources and modify the build by changing the input to CMake. They are not required to know how to edit and maintain files for make/ninja/VS 9,10,11,12,13,14, Xcode various versions. - You should use out of source builds and once a build generator is picked (VS some version, make, ninja, ect), You can not change that build generator without erasing the directory or creating a new one. - It might be possible in future versions of CMake that VS IDEs support 64/32 bit builds like they support release/debug right now, but currently this is not supported in a
Re: [CMake] Changing the the current generator in CMake GUI
http://reactiongifs.me/krysten-ritter-eyeroll/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
>You can not change the generator. It is better to remove the entire >build tree. Out of source builds are a best practice with CMake. Once >a build tree has been configured with one compiler, it must be >completely removed to change to a new compiler Clearly, "can not" is incorrect, since I did. "must be" seems also incorrect. It seems like the developers don't understand about 32-bit vs. 64-bit builds, or don't intend for this tool to be used with software that is a product. Determining that after painstakingly configuring all of the build options, the user must throw it all away in order to build for the other "bitness", seems wrong. Almost anyone that is intending to build software that can be installed (without the end user having to build it from source every time, that way lies madness) needs to produce a 32-bit and a 64-bit package these days. >CMake creates VS projects that should >work to build the project that is the goal. I don't understand about >make and MSVS, CMake can create makefiles or ninja files if that is what >you are talking about. The VC project files produced by the CMAKE system for OpenCV use absolute paths and use them throughout the project files, rather than defining things at top-level and then using predetermined macros like $(TargetDir) and $(TargetName), to say nothing of conveniences like $(PlatformTarget). I don't really know if that is inherent in how CMAKE generates the project files or if there is a way to produce more easily maintainable project files, but every time I have to utilize a project that involves CMAKE I cringe because of the ugly project files it produces. The makefiles produced have been the same way, with the same absolute paths occurring over and over in the file. I do not like this, as it makes the project files/makefiles difficult to debug or maintain. Having expressed this dislike here, I feel much better and will probably not think about this much in the future, up until the point I have to update to a new version of a library such as OpenCV or HDF5. Then I will cringe; pick through all of the settings and generate the makefiles/project files again; debug the results for a day or so until the builds actually, you know, work; and then do my little edit-and-regenerate trick to build for the other architecture. Because the design of CMAKE does not recognize that the results of "try-compile" tests are orthogonal to settings like "build module A" or "build shared libraries", so that the latter should not depend upon the former. -- View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
know if that is inherent in how CMAKE generates the project > files or if there is a way to produce more easily maintainable project > files, but every time I have to utilize a project that involves CMAKE I > cringe because of the ugly project files it produces. The makefiles produced > have been the same way, with the same absolute paths occurring over and over > in the file. I do not like this, as it makes the project files/makefiles > difficult to debug or maintain. Having expressed this dislike here, I feel > much better and will probably not think about this much in the future, up > until the point I have to update to a new version of a library such as > OpenCV or HDF5. Then I will cringe; pick through all of the settings and > generate the makefiles/project files again; debug the results for a day or > so until the builds actually, you know, work; and then do my little > edit-and-regenerate trick to build for the other architecture. Because the > design of CMAKE does not recognize that the results of "try-compile" tests > are orthogonal to settings like "build module A" or "build shared > libraries", so that the latter should not depend upon the former. > > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 1/15/2016 11:26 AM, mozzis wrote: You can not change the generator. It is better to remove the entire build tree. Out of source builds are a best practice with CMake. Once a build tree has been configured with one compiler, it must be completely removed to change to a new compiler Clearly, "can not" is incorrect, since I did. "must be" seems also incorrect. You can do it by changing the CMakeCache.txt file, but it won't work in the general case. You should put them in separate directories: build-32 and build-64. It seems like the developers don't understand about 32-bit vs. 64-bit builds, or don't intend for this tool to be used with software that is a product. Determining that after painstakingly configuring all of the build options, the user must throw it all away in order to build for the other "bitness", seems wrong. Almost anyone that is intending to build software that can be installed (without the end user having to build it from source every time, that way lies madness) needs to produce a 32-bit and a 64-bit package these days. You can build both 32 and 64 from the same SOURCE tree, just not the same build tree. src build32 (cmake ../src -G"Visual Studio 10 2010") build64 (cmake ../src -G"Visual Studio 10 2010 Win64") You seem to be trying to reuse the same build tree for different builds which is not a supported use case. I think if you stopped doing that your life might get easier when working with CMake projects. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Bill Hoffman wrote: You can do it by changing the CMakeCache.txt file, but it won't work in the general case. You should put them in separate directories: build-32 and build-64. You can build both 32 and 64 from the same SOURCE tree, just not the same build tree. build32 (cmake ../src -G"Visual Studio 10 2010") build64 (cmake ../src -G"Visual Studio 10 2010 Win64") You seem to be trying to reuse the same build tree for different builds which is not a supported use case. I think if you stopped doing that your life might get easier when working with CMake projects. You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit. Because of that, they're "not pushing too hard" for it to be in mainline CMake. https://cmake.org/pipermail/cmake/2015-August/061346.html -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 1/15/2016 2:41 PM, Greg Marr wrote: You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit. Because of that, they're "not pushing too hard" for it to be in mainline CMake. https://cmake.org/pipermail/cmake/2015-August/061346.html Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. However, if you want cmake builds to work, you should never change the generator in a CMakeCache.txt file, it is going to more often than not cause problems. A build tree should be configured with one generator and if you need another generator you should use a different directory and a different build tree sharing the same source tree. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Bill Hoffman wrote: >On 1/15/2016 2:41 PM, Greg Marr wrote: >> You can do both in the same solution/projects with the Microsoft fork >> of CMake, but it's not a general solution, and it doesn't handle >> different settings for 32 bit and 64 bit. > >Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. Correct, so if you require different settings based on that value, you can't use this solution. However, if you never look at it, then this may work for you. > However, if you want cmake builds to work, you should never change the > generator in a CMakeCache.txt file, it is going to more often than not > cause problems. A build tree should be configured with one generator > and if you need another generator you should use a different directory > and a different build tree sharing the same source tree. Absolutely, that's why this is a single generator and is generated once. Unfortunately, the different settings limitation of this solution is rather...limiting. It would be really nice if this could be made to work with different settings for the different CPU architectures (mostly just library paths for my past uses), just like native Visual Studio, XCode, Eclipse, and Android Studio projects do, but that would apparently be a very major change. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Well, CMAKE is the thing that is conflating this idea of a "generator" (which is clearly a concept in CMAKE's own domain of "build configuration generator") with the idea of "platform" or "architecture" (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It would be healthier if platform/arch were broken out as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools have this concept, but is (possibly) agnostic about how it is represented. I assume that it is not really possible to do so in the config files that drive CMAKE at present, only because I have never seen it done and did not find it when I went looking. Instead, that information is scattered across several files in the CMakeFiles folder. Thank you for the hints and examples about using batch files. I may try to implement that scheme for building support libraries that come dependent on CMake. But I don't believe that I will ever use CMake for any product I am in control of, mainly because I have seen what an unmaintainable mess it creates for project files. And at least partly as a result, since there is no direct comprehension on the part of the developer/maintainer as to the project file structure, it becomes impossible to adequately manage that structure, so making large-scale improvements is nearly impossible without starting over from scratch. In addition, the build process becomes way inefficient. For example, once when I was really at loose ends due to a management blow-up, I reworked the build system for HDF5 on Visual Studio so it had "normal" project files that could be used to build for various platforms and configurations. The resulting build time was cut by a factor of 5, plus it became much easier (for me anyways) to be able to do things like change the output file names based on platform, something I have so far found impossible to do with CMake. [Once again, it really has no concept of this.] I would do the same thing for OpenCV, but it is ten times worse than HDF5 in this regard. For instance, apparently project files are modified as part of the MSVS build process, so that Visual Studio always complains about project files needing to be reloaded after a build. This is a recipe for mysterious bugs that you will never be able to fix. I have created/maintained multi-platform projects, and I find that the effort needed to produce efficient, readable makefiles for each platform is worth it. Once done, I can change the platform or the library type or similar parameters by changing one switch in each platform's makefile. Plus there are fewer gotchas at runtime, as not querying the build environment for every build ensures more consistent behavior in the binaries I am going to distribute. Thanks again to all for the comments on this thread. It is good to know that development continues on this tool. At some point, it may become more interesting for me. From: J Decker [via CMake] [mailto:ml-node+s3232098n7592504...@n2.nabble.com] Sent: Friday, January 15, 2016 1:10 PM To: Morris Maynard <mor...@maynidea.com> Subject: Re: Changing the the current generator in CMake GUI On Fri, Jan 15, 2016 at 8:26 AM, mozzis <[hidden email]> wrote: > > Clearly, "can not" is incorrect, since I did. "must be" seems also > incorrect. Changing Generator is not exactly the same idea of what you're doing 1) If you actually chaned from VS 2010 to VS2012 or more radically to MinGW Makefiles and redid the build, you would have only partially correct results. And actually even changing the bitness you already have products built (.obj files) which won't be retriggered to compile to some other flavor since the .obj will aready be newer than the source so you'd have to do a rebuild. > It seems like the developers don't understand about 32-bit vs. 64-bit > builds, or don't intend for this tool to be used with software that is a > product. Determining that after painstakingly configuring all of the build > options, the user must throw it all away in order to build for the other > "bitness", seems wrong. Almost anyone that is intending to build software > that can be installed (without the end user having to build it from source > every time, that way lies madness) needs to produce a 32-bit and a 64-bit > package these days. > This is 2 different packages, 2 different targets, (4 if you distribute debug versions also). The packing stage will really expect separate targets. However, I solve this by making simple 'makeit.bat' scripts. copy and replace the generator and go. But it also sounds like you're trying to get Cmake to play with existing builds instead of treating cmake as the primary build system. I fought with this a bit and was discusted myself in the lack of conformance to default project $(outputdir)/$(targetname) stuff. Was expectin
Re: [CMake] Changing the the current generator in CMake GUI
I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI closed) I changed CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64 to CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 and then in general looked for the string "64" and made appropriate changes. I then started CMake GUI, noted that the "Current Generator" was to my liking, and did Configure and Generate steps again. All in all, doesn't seem that it would be too hard for CMake devs to implement a function to do this, but IMO Cmake is a mistake anyway, I only use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project files, and makes it much harder to maintain projects that use it. Which I guess is kind of the opposite of the intended effect. More intelligent use of existing macros for both make and MSVS would go a long way to making it useful. -- View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592486.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 1/14/2016 3:02 PM, mozzis wrote: I was able to edit CMakeCache.txt and CPackConfig.cmake (with CMake GUI closed) I changed CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 Win64 to CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 and then in general looked for the string "64" and made appropriate changes. I then started CMake GUI, noted that the "Current Generator" was to my liking, and did Configure and Generate steps again. You can not change the generator. It is better to remove the entire build tree. Out of source builds are a best practice with CMake. Once a build tree has been configured with one compiler, it must be completely removed to change to a new compiler. You are changing from 32 bit to 64 bit, this means that all the try-compile stuff needs to be re-run as the answers are likely to be different. All in all, doesn't seem that it would be too hard for CMake devs to implement a function to do this, but IMO Cmake is a mistake anyway, I only use it when forced (e.g., OpenCV.) CMake butchers MS Visual Studio project files, and makes it much harder to maintain projects that use it. Which I guess is kind of the opposite of the intended effect. More intelligent use of existing macros for both make and MSVS would go a long way to making it useful. Thanks for the praise... :) CMake creates VS projects that should work to build the project that is the goal. I don't understand about make and MSVS, CMake can create makefiles or ninja files if that is what you are talking about. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 7/12/2014 8:17 AM, Bill Hoffman wrote: You can use clear cache. Just to be clear. If you want to change the current generator, you can use File - Delete Cache. Then you will be able to select a new generator for that directory. I guess the GUI could be change to have a change generator button that gave a big huge warning that it Cache was getting deleted could be done. Or we could address it with documentation. We do welcome contributions if you are interested. See: https://github.com/Kitware/CMake/blob/master/CONTRIBUTING.rst Thanks. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 7/11/2014 11:01 AM, Bill Hoffman wrote: On 7/11/2014 10:33 AM, Edward Diener wrote: Shouldn't there be a way to change the current generator in the CMake GUI ? It seems like I can only do this if I choose a new Where to build the binaries path. But what if I just want to change the current generator to something else using the current outpath path ? No, once the generator is set and you have run cmake once, you need to create a new build tree or wipe out the one you created the first time. CMake stores a bunch of information about the compiler in the cache and other files in the build tree. It does not know how to change all that without a clean tree. It does not seem like cleaning the build tree from within the CMake GUI should be a hard programming task, if the end-user wishes to change the current generator. Nonetheless thanks for the information. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
You can use clear cache. On Jul 12, 2014 5:05 AM, Edward Diener eldlistmaili...@tropicsoft.com wrote: On 7/11/2014 11:01 AM, Bill Hoffman wrote: On 7/11/2014 10:33 AM, Edward Diener wrote: Shouldn't there be a way to change the current generator in the CMake GUI ? It seems like I can only do this if I choose a new Where to build the binaries path. But what if I just want to change the current generator to something else using the current outpath path ? No, once the generator is set and you have run cmake once, you need to create a new build tree or wipe out the one you created the first time. CMake stores a bunch of information about the compiler in the cache and other files in the build tree. It does not know how to change all that without a clean tree. It does not seem like cleaning the build tree from within the CMake GUI should be a hard programming task, if the end-user wishes to change the current generator. Nonetheless thanks for the information. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Changing the the current generator in CMake GUI
Shouldn't there be a way to change the current generator in the CMake GUI ? It seems like I can only do this if I choose a new Where to build the binaries path. But what if I just want to change the current generator to something else using the current outpath path ? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On Fri, Jul 11, 2014 at 10:33 AM, Edward Diener eldlistmaili...@tropicsoft.com wrote: Shouldn't there be a way to change the current generator in the CMake GUI ? It seems like I can only do this if I choose a new Where to build the binaries path. But what if I just want to change the current generator to something else using the current outpath path ? You can also do this if you reset the cache in cmake-gui. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 7/11/2014 10:33 AM, Edward Diener wrote: Shouldn't there be a way to change the current generator in the CMake GUI ? It seems like I can only do this if I choose a new Where to build the binaries path. But what if I just want to change the current generator to something else using the current outpath path ? No, once the generator is set and you have run cmake once, you need to create a new build tree or wipe out the one you created the first time. CMake stores a bunch of information about the compiler in the cache and other files in the build tree. It does not know how to change all that without a clean tree. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
