[CMake] Changing the the current generator in CMake GUI

[Bill Hoffman]

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
> <i>/as part of the MSVS build process/</i>, 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 released CMake.  If it were 
supported projects would have to be careful with try-compile/try-run 
commands.

-Bill