I make heavy use of the add_custom_command feature for compiling CUDA code with FindCUDA.cmake.  Lately when doing more and more developement with VS 2010, I've experiences several issues with the Custom Build Tool as implemented by MSbuild.  I've filed three bugs with Microsoft, and all but one so far has been marked as "Works as intended" which is quite unfortunate.<br>

<br>1. All custom build targets will rerun if there is an error with a single rule during execution [1].  This bug is currently still open.<br>2. Custom build rules must be run for each configuration at least once to populate their helper files even if the output is up to date. [2] This bug is marked as "By Design".<br>

3. Once the custom build targets are started, you cannot stop the build until they are all finished [3].  This bug is marked as "By Design".  I haven't verified yet that this behavior can be worked around with a new build rule. <br>

<br>I wanted to get a pulse from the developers what they think about the following.  I'm willing to help where I can, but I'm hoping that there could be some collaboration on this.<br><br>What I'm envisioning is developing a new custom build tool, call it CMake Custom Command (or CCC for short), that can implement one new feature above and beyond the existing one and fix some of the issues with the existing version.  CCC would be copied into or created in the build directory and the solution/projects will point to it explicitly.  This would prevent having to install it in the VS directories and could be easily be changed on a per build basis if needed.  CCC would do the following.<br>

<br>1. Optionally track dependencies in a separate file externally to the project.  According to this [4] post this should be possible with MSbuild rules.  This would prevent project reloading for custom commands that like to auto generate source level dependencies.<br>

2. Keep dependency tracking separate for each command.  This is a cause of no end of grief with the current MSbuild Custom Build Tool which track the dependencies for an entire project in the same file (technically there are three files where each target has its own entry in each file).<br>

3. We can make sure that if your output is configuration independent, you don't have to run the rule for each configuration.<br>4. We could run the rule with the arguments to the command change, but to help with #3 we could "prewarm" the state files at configure time instead of at build time to avoid having to run the rule to fill in these state files saving recompilation.<br>

<br><br>What do people think?  This is kind of a big hammer to fix problems with MSbuild, but isn't CMake supposed to help work around annoying bugs in VS. :)<br><br>James Bigler<br><br>[1] 
<a href="https://connect.microsoft.com/VisualStudio/feedback/details/704151/build-failure-in-single-custom-command-results-in-all-custom-commands-being-rerun">https://connect.microsoft.com/VisualStudio/feedback/details/704151/build-failure-in-single-custom-command-results-in-all-custom-commands-being-rerun</a><br>


[2] 
<a href="https://connect.microsoft.com/VisualStudio/feedback/details/704157/custom-build-tool-shouldnt-have-to-run-if-targets-are-up-to-date">https://connect.microsoft.com/VisualStudio/feedback/details/704157/custom-build-tool-shouldnt-have-to-run-if-targets-are-up-to-date</a><br>


[3] <a href="https://connect.microsoft.com/VisualStudio/feedback/details/704160/cannot-stop-custom-build-commands-during-compilation">https://connect.microsoft.com/VisualStudio/feedback/details/704160/cannot-stop-custom-build-commands-during-compilation</a><br>


[4] <a href="http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7a0696cf-fcc4-44ee-8444-096f64e538b6">http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7a0696cf-fcc4-44ee-8444-096f64e538b6</a><br><br>