>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
