Re: [CMake] ExternalProject and clean targets
IIRC for Visual Studio I had opposite problem: clean on external project
didn't triggered rebuild.
On Sat, Oct 15, 2011 at 2:34 PM, David Cole david.c...@kitware.com wrote:
On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling mhertl...@online.de
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/cmake@cmake.org/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
Re: [CMake] ExternalProject and clean targets
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/cmake@cmake.org/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
Re: [CMake] ExternalProject and clean targets
On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling mhertl...@online.de 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/cmake@cmake.org/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
Re: [CMake] ExternalProject and clean targets
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 mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
Sent from my mobile device.
On Oct 15, 2011, at 6:35, David Cole david.c...@kitware.com wrote:
On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling mhertl...@online.de 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/cmake@cmake.org/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
Re: [CMake] ExternalProject and clean targets
On 10/15/2011 12:34 PM, David Cole wrote:
On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling mhertl...@online.de 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/cmake@cmake.org/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
Ah, I see. Would it be an alternative to get the external projects'
stamp files out of the way, trigger the top-level project's clean
target and restore the stamp files right after that? If I add the
following to the above-noted top-level CMakeLists.txt
ExternalProject_Get_Property(external STAMP_DIR)
SET(DIRS ${STAMP_DIR}) # Mind the separator.
ADD_CUSTOM_TARGET(tl-clean
COMMAND ${CMAKE_COMMAND} -DDIRS=${DIRS} -DSEP=:
-P ${CMAKE_SOURCE_DIR}/savestampfiles.cmake
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--target clean
COMMAND ${CMAKE_COMMAND} -DDIRS=${DIRS} -DSEP=:
-P ${CMAKE_SOURCE_DIR}/restorestampfiles.cmake)
with
# savestampfiles.cmake:
STRING(REPLACE ${SEP} ; DIRS ${DIRS})
FOREACH(i IN LISTS DIRS)
FILE(GLOB FILES ${i}/*)
FOREACH(j IN LISTS FILES)
FILE(RENAME ${j} ${j}.bak)
ENDFOREACH()
ENDFOREACH()
# restorestampfiles.cmake:
STRING(REPLACE ${SEP} ; DIRS ${DIRS})
FOREACH(i IN LISTS DIRS)
FILE(GLOB FILES ${i}/*.bak)
FOREACH(j IN LISTS FILES)
STRING(REGEX REPLACE \\.bak\$ k ${j})
FILE(RENAME ${j} ${k})
ENDFOREACH()
ENDFOREACH()
a make tl-clean in CMAKE_BINARY_DIR cleans the top-level project
- not the external ones' targets - as
[CMake] ExternalProject and clean targets
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? -- Lori A. Pritchett-Sheats, PhD. CCS-2, Computational Physics and Methods Office: 505-665-6675 Fax: 505-665-4972 Los Alamos National Laboratory P.O. Box 1663 MS D413 Los Alamos, NM 87544 -- 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
