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
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
