<div class="gmail_quote">On 6 July 2011 17:27, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">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><br>Oops, no I didn't mean to omit the mailing list.<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>
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>Glenn<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div><div class="gmail_quote">On Wed, Jul 6, 2011 at 12:24 PM, 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">
<div>On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs <span dir="ltr"><<a href="mailto:glenn.coombs@gmail.com" target="_blank">glenn.coombs@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On 5 July 2011 17:13, 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">
<div class="gmail_quote"><div>It is (intentionally) missing some functionality. You have not misunderstood.<br><br>The general case of ExternalProject is completely arbitrary, although we do use reasonable default commands for cmake projects and configure/make projects as they are conventionally used... Since it's completely arbitrary, we do not know if there is a 'clean' target at each level.<br>
</div></div></blockquote></div><div><br>Don't all projects configured using cmake have a clean target ? Certainly the makfiles on linux have a clean target, and the Visual Studio projects can all be individually cleaned. It looks like ExternalProject_Add() already adds special case targets for test and install so that they end up calling:<br>
<br> cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target test<br> cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target install<br><br>Would it not make sense to also add a special target for clean in the same manner ?<br>
</div></div></blockquote><div><br></div></div><div>It would make sense. But there is no "--target clean" on Visual Studio builds. Visual Studio has a clean mechanism, not a clean build target. So the API for doing a clean operation is inconsistent across all CMake generators. If it were consistent, I might be inclined to agree with you, but it's not.</div>
<div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
</div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class="gmail_quote"><div>The best 'clean' is starting with an absolutely empty build tree, and running CMake and your build system from there.</div>
<div><br></div><div>Since the best 'clean' is always going to be better than any target-based clean we could come up with, I wouldn't even attempt to add this functionality unless nearly everybody unanimously agreed that we should have it. And only then if somebody writes a patch to provide it.</div>
</div></blockquote></div><div><br>On those grounds why do the cmake generated makefiles provide a clean target ? <br></div></div></blockquote><div><br></div></div><div>Because it was already here when I got here. :-) I'm pretty sure the primary motivation is because some projects have ridiculously long initial configuration times, and avoiding that by keeping the cache while blowing away the object files is useful to some... Personally, I'd rather see folks work on minimizing their configure times.</div>
<div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br>Given that the infrastructure for cleaning is already present in cmake configured projects what reason is there to deliberately omit the code to call that funcionality ?<br>
</div></div></blockquote><div><br></div></div><div>As mentioned above, there is no consistent API that is convenient for calling from the ExternalProject code available. If it were available, I'd say we could do it. As it stands, I think it's better left to full clean and rebuild by the end users.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<br>--<br>Glenn<br><br></div></div>
</blockquote></div><br><div><br></div><div>Thanks,</div><div>David</div><font color="#888888"><div><br></div>
</font></blockquote></div><br></div><div class="h5">
</div></div></blockquote></div><br>