[cmake-developers] Build rules for CMakeLists.txt files

Brad King brad.king at kitware.com
Mon Aug 15 12:45:21 EDT 2011


On 8/9/2011 6:25 PM, James Bigler wrote:
> I guess a different question I should be asking is why is the CMakeLists.txt
 > build rule running after my other custom rules.  It seems to me that the
 > CMakeLists.txt build rule should *always* be the first thing to build in a
 > given project.

We cannot control how VS decides to evaluate the rules.  It may notice that
the CMake input file changes during the build and then decide to update that
rule (i.e. re-run CMake).

> On Tue, Aug 9, 2011 at 4:06 PM, James Bigler wrote:
>> I wonder how hard it would be to just not add build rules to the
 >> CMakeLists.txt files......

This is probably not too hard.  Having the rules only in the ZERO_CHECK
target would be sufficient for most cases.  However, the intended interface
is for people to be able to edit the CMakeLists.txt in the IDE and then
right-click => compile to re-run CMake.  Turning this off should be
optional (though the option can be set by the project's own CMakeLists.txt
files rather than by every user).  The CMAKE_SUPPRESS_REGENERATION option
already does this, but it also removes the files.  You're proposing a
middle ground.

Look at cmLocalVisualStudio7Generator::CreateVCProjBuildRule to try
implementing this middle ground.  Here one could create the cmSourceFile
instance for CMakeLists.txt without actually adding a custom rule to it.

BTW, build-time dependency scanning in VS is not possible AFAIK without
writing a VS plugin that needs to be installed on every build machine.
An alternative is to create custom rules that drive entire configure
and build processes in separate build trees (e.g. ExternalProject_Add).
That way one custom target can generate the source files that will be
picked up by dependency scanning during the *configuration* of the
second (inner) build tree.

-Brad



More information about the cmake-developers mailing list