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