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