Post by Bill HoffmanPost by Robert DaileyThe only trouble these projects are causing me is clutter. There is
no
Post by Bill HoffmanPost by Robert Daileyfunctional purpose for them as far as I know, which is another
reason
Post by Bill HoffmanPost by Robert Daileywhy I do not like them.
set(CMAKE_SUPPRESS_REGENERATION TRUE)
I think that will get rid of ZERO_CHECK, but I am not sure. Again,
this
Post by Bill Hoffmanwill potentially break your builds, and make them less reliable.
ZERO_CHECK is used to make sure that the project files are up-to-date
relative to the CMakeLists.txt files. It is also used to check some
depend information that VS does not do.
And what this supports is the ability to incrementally build the VS
project files themselves, not just the source files in the projects.
What I've noticed in Visual Studio 6 builds using CMake--which don't
have a ZERO_CHECK project--is that I edit one of my CMakeLists.txt
files, then click "Build", and sure enough CMake generates a new DSP
file for that project; but then it continues building that same project
without reloading, which of course doesn't do what I want, and I have to
click "Build" again in order to make my project compile the way it's
supposed to. And sometimes it still doesn't quite recover correctly.
In my current Visual Studio 2008 builds using CMake, this process
appears to work smoother--and I'm guessing it's because these builds
have a ZERO_CHECK project.
But if you were still thinking of the Visual Studio files as static
source files that you edit "by hand", then you wouldn't think of the
CMakeLists.txt files as source files on which you might want to detect
changes and trigger incremental builds, just as you trigger an
incremental build when you edit one of your C++ source files.
So yes, clearly you can make all your own vcproj and sln files directly
in Visual Studio and build software successfully. I just got sick of
continually cutting and pasting in and out of awkward windows and
clicking on all the numerous things I had to click to get each project's
settings correctly, and CMake offered a way to avoid all that nonsense
by defining all the repeated stuff once in a kind of "macro", and
furthermore an easy way to do out-of-source builds, which I could do
with "make" but could never see a practical way to do from within Visual
Studio's own project editor. Moreover, I found that CMake really could
produce both a Visual Studio workspace and a Linux makefile for a
substantial project, giving me both of these for less than it cost me
just to port a workspace to a makefile by hand.
In that substantial project, the handy thing about ALL_BUILD was that it
was in fact the one project you could build if you wanted everything in
the workspace to be built; several of the other projects were
executables, each of which had nothing except ALL_BUILD depending on it,
so without a project like ALL_BUILD we would have had either to build
every single one in succession or else to invent some other (much worse)
artificial dependency between projects. But even in a simple project
where there's already one project that depends on all others, I'd live
with the existence of ALL_BUILD in return for all the other stuff. At
least it doesn't actively _prevent_ me from doing something I need to
do.
But if you really love a carefully crafted Visual Studio "solution",
with every box in every project carefully and individually filled in or
checked off or left empty by a human hand with loving personal care,
then CMake is not for you.
David Karr