IIRC for Visual Studio I had opposite problem: clean on external project didn't triggered rebuild.<br><br><div class="gmail_quote">On Sat, Oct 15, 2011 at 2:34 PM, 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;"><div><div></div><div class="h5">On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling <<a href="mailto:mhertling@online.de">mhertling@online.de</a>> wrote:<br>
> On 10/12/2011 10:22 PM, Lori Pritchett-Sheats wrote:<br>
>><br>
>> I'm building external packages in my CMake system using the<br>
>> ExternalPackages_Add function. When a package is built this way and I<br>
>> execute a 'make clean' at the top of my build tree, all targets are<br>
>> cleaned including the external packages. Is there a way to remove the<br>
>> external package targets from the the default clean target?<br>
><br>
> The following exemplary project does not exhibit this behavior:<br>
><br>
> # CMakeLists.txt:<br>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)<br>
> PROJECT(CLEAN C)<br>
> SET(CMAKE_VERBOSE_MAKEFILE ON)<br>
> INCLUDE(ExternalProject)<br>
> ExternalProject_Add(external<br>
> SOURCE_DIR ${CMAKE_SOURCE_DIR}/external<br>
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>)<br>
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")<br>
> ADD_EXECUTABLE(main main.c)<br>
> ADD_DEPENDENCIES(main external)<br>
> INSTALL(TARGETS main DESTINATION bin)<br>
><br>
> # external/CMakeLists.txt:<br>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)<br>
> PROJECT(EXTERNAL C)<br>
> SET(CMAKE_VERBOSE_MAKEFILE ON)<br>
> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")<br>
> ADD_LIBRARY(f SHARED f.c)<br>
> INSTALL(TARGETS f DESTINATION lib)<br>
><br>
> After configuring and building:<br>
><br>
> % ls main external-prefix/src/external-build/libf.so<br>
> external-prefix/src/external-build/libf.so main<br>
><br>
> After "make clean" in CMAKE_BINARY_DIR:<br>
><br>
> % ls main external-prefix/src/external-build/libf.so<br>
> ls: cannot access main: No such file or directory<br>
> external-prefix/src/external-build/libf.so<br>
><br>
> The top-level project's target is gone whereas the external project's<br>
> one is intact, and [1] reports the same, i.e. the opposite of your<br>
> concern. Thus, could you boil down your issue to a minimal but<br>
> self-contained example for further investigation?<br>
><br>
> Regards,<br>
><br>
> Michael<br>
><br>
> [1] <a href="http://www.mail-archive.com/cmake@cmake.org/msg35411.html" target="_blank">http://www.mail-archive.com/cmake@cmake.org/msg35411.html</a><br>
> --<br>
><br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
><br>
<br>
</div></div>When Lori said "all targets are cleaned including the external<br>
packages" I think she meant that she would like the ExternalProject<br>
stamp files to remain intact across a "clean" such that the<br>
ExternalProject steps do not re-execute on the next make. Is that<br>
indeed what you meant, Lori?<br>
<br>
If so, I do not know of an easy way to achieve that goal.<br>
<br>
One thing that comes to mind is separating out the parts that you<br>
don't want to re-build after a clean into a separate project, and<br>
build/[install] that into a place where you can reference the<br>
built/installed products from a second project in which you frequently<br>
'clean'...<br>
<br>
Another alternative would be to avoid the top-level clean altogether,<br>
and simply go down into an individual external project's build tree<br>
and do the make clean in there so as to only clean the individual<br>
project you're immediately working with.<br>
<br>
I've frequently thought we should cache/share ExternalProject builds<br>
across other multiple builds that could reference them.... but I<br>
hesitate to put legs on that idea because of possibly introducing easy<br>
ways to create giant tangled messes of projects with incompatible<br>
compiler/linker flags. It's worth keeping on the idea pile, though,<br>
and a motivated individual could certainly already achieve this by<br>
placing the build/install products of ExternalProject_Add calls in<br>
shared locations (i.e., in the HOME directory instead of as<br>
sub-directories of the present build tree).<br>
<br>
<br>
HTH,<br>
<font color="#888888">David<br>
</font><div><div></div><div class="h5">--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>