[Cmake] Unwanted automatic rebuilding of Visual Studio projects

[Ken Martin]

Hello David,

> When I edit one of the CMake files, e.g. CMakeLists.txt, and
> rebuild my workspace in Visual Studio, all the affected .dsp
> files are modified, causing Visual Studio to prompt me to
> reload each of those projects.  This is a behavior that makes
> sense, although it is annoying when I forget to close my workspace
> before editing a file that affects all projects, because there
> are dozens of projects in this workspace and Visual Studio wastes
> a lot of my time prompting me for each one individually.

FYI, Visual Studio 7 doesn't prompt for each file, a nice improvement.

In old versions (before 1.6 I think) CMake would rewrite the dsp files =
when
it wasn't necessary causing the reload that you see to occur. Since then =
we
have modified this so that CMake does a "copy if different" so it may
regenerate the dsp files but doesn't actually overwrite them unless they
have changed. If developers (using CMake 1.6 or later I believe) are =
seeing
requests for the dsps to be reloaded it is either because they have =
changed
or because something else is modifying them other than CMake.=20

> What is even more annoying is when all these .dsp files get
> touched somehow when nobody has edited any of the input to CMake.
> That is, for no apparent reason (other than that the developer is
> trying to compile a newly-edited C++ source file, which of course
> is a very frequent occurrence), Visual Studio will start
> prompting the developer to reload each one of the several dozen
> projects in the workspace.

This is something I haven't seen yet. CMake should not regenerate a dsp =
file
just because someone edited some source code. If they edit the =
CMakeLists
file or some other cmake list files that are included in the CMakelists =
file
then it will rerun and possibly generate new dsps. But there is no =
reason
why editing source files should cause CMake to rerun. We do this all the
time and do not see this behavior. Clearly you are seeing it so =
something is
up.

> One of the developers on my project is seeing this happen
> repeatedly while working in a ClearCase dynamic view.
> Other developers have noticed the same thing in snapshot views
> or even in ordinary (not source-controlled) folders on hosts
> whose system clocks are a bit irregular (apparently these
> hosts keep getting out of synch with a time server and get
> their clocks automatically reset from time to time).
> I'm almost sure none of these developers was actually
> editing any of the CMake input files at any time near when
> the .dsp files got regenerated; it seems to be just a timing
> glitch of some sort.
>=20
> My question is, is there any way to make our workspace less
> susceptible to this kind of unpleasant behavior?

Sure, we just need to figure out who is changing the dsp files. One =
thing we
do to track down a problem like this is to load the workspace and build.
Then we copy the current dsp file to some backup file. Then do whatever
causes the dsp to be modified. Then compare the two dsp files to see =
what is
different. Something must be changing in the dsp file otherwise CMake =
would
not modify the file. Sometimes seeing the diffs between the two helps =
clear
up the issue.


> I have a batch file that initially runs CMake to create the
> workspace and all the .dsp files, and we'd be happy if this
> were the *only* way CMake was run, rather than having rules
> in the .dsp files themselves to re-run CMake.  Of course
> then we'd have to remember to run CMake manually when something
> actually changed, but that's a small inconvenience compared to
> what we're facing now.  But it seems that CMake automatically
> adds the rule for CMakeLists.txt to each .dsp file and there
> seems to be no way to turn this feature off other than by
> compiling and running a hacked version of CMake itself.
> Is there a better way?

There is an undocumented way to turn this feature off but something =
funny is
going on in your setup. I'd like to try tracking down the problem so we =
can
get it fixed. Also if you could tell us what version of CMake you are
running that would help.

Thanks
Ken