[CMake] Changing the the current generator in CMake GUI

mozzis morris at maynidea.com
Fri Jan 15 11:26:01 EST 2016


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


More information about the CMake mailing list