<div class="gmail_quote">On Thu, Jul 7, 2011 at 7:36 AM, Glenn Coombs <span dir="ltr"><<a href="mailto:glenn.coombs@gmail.com">glenn.coombs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On 6 July 2011 17:27, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Don't know if you meant to omit the CMake mailing list on that, or if that was on oversight.... Feel free to put my responses back on list if you wish.)</blockquote></div><div><br>Oops, no I didn't mean to omit the mailing list.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div>One
more point: ExternalProject is completely and fully customizable. You
could certainly add a "clean" step to any ExternalProject that you like.
Or you could define a "clean_externals" at the top level that goes and
cleans everything. If you can figure out the right clean
sub-commands.....<br>
</div></blockquote><br></div>
I'm not sure but wouldn't getting clean to work with Visual Studio
require changes to the generator code to add hooks in the vcproj files
on either the BeforeClean or AfterClean events ? As far as I can tell
Visual Studio cleans a project by deleting the files it thinks the
project creates. For normal C/C++ projects this works as expected but
for external projects the created files are not known in the external project vcproj file. However, they are known in the subdirectory external project vcproj file. To clarify, in my case the external project has these 2 vcproj files:<br>
<br><buildDir>/external_proj.vcproj<br><buildDir>/external_proj/src/external_proj-build/myProjName.vcproj<br><br>The top level external_proj.vcproj file only contains a folder of CMakeBuildRules which specify custom build commands for each of the configure, build, install etc. steps. When this top level project is built it invokes cmake --build <buildDir>/external_proj/src/external_proj-build to do the actual build.<br>
<br>If I clean external_proj then it has no idea what to delete under the <buildDir>/external_proj/src/external_proj-build directory. But if cmake had hooked the AfterClean event on external_proj and then called cmake --build <buildDir>/external_proj/src/external_proj-build --target clean then that would get Visual Studio to clean the lower level myProjName.vcproj which does know which files to clean because it is a normal C/C++ project.<br>
<br>The top level external_proj is the only one visible in Visual Studio. The lower level myProjName is not visble in Visual Studio but it is the only one that knows how to do the clean. If the top level one forwarded the clean to it then everything would work.<br>
<br>I haven't checked but I suspect the same thing would work for the Makefile generators. The top level "make clean" would just call "make clean" on the lower level makefile.<br><br>--<br><font color="#888888">Glenn<br>
<br></font></div></div></blockquote><div><br>I'm sure that what you want to do is possible. I'm also sure that it's a huge effort to get it to work with all CMake generators. It will also be difficult to write a good test of the functionality.<br>
<br>Furthermore, I view it as largely unnecessary work...<br><br>...because a full file-system-level clean of deleting the entire build tree, followed by a quick configure with CMake of the top level project, followed by a regular build has largely the same net result with negligible difference in total build time. If the difference in total build time is non-negligible, and really annoying to somebody, then this huge effort may well be worth it to them, at that point in time.<br>
<br>Right now, I'm not convinced the extra effort and extra complications in the code are worthwhile additions to CMake.<br><br><br>Respectfully,<br></div></div>David<br><br>