On 7/7/2011 11:37 AM, Glenn Coombs wrote:
I understand where you're coming from on the resources front. There
would obviously be some effort required to get this to work properly.
I'm not convinced it is such a huge amount of work as you're suggesting,
but then I don't know the source code as well as you do :-)
From my point of view this does make using ExternalProject_Add() a less
interesting option. Yes, I can tell users that they have to manually
delete a sub-tree and re-run the configure step and then rebuild the top
level project. But realistically that isn't going to fly for the
majority of users, especially the Visual Studio users. They just want
to select build, or rebuild and expect it to work.
If I get some spare time I will investigate further what would be involved.
You should be able to use the cmake --build to do a portable clean of
targets.
Usage: cmake --build <dir> [options] [-- [native-options]]
Options:
<dir> = Project binary directory to be built.
--target <tgt> = Build <tgt> instead of default targets.
--config <cfg> = For multi-configuration tools, choose <cfg>.
--clean-first = Build target 'clean' first, then build.
(To clean only, use --target 'clean'.)
-- = Pass remaining options to the native tool.
That should work with this suggestion:
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.....
${CMAKE_COMMAND} --build path/to/bin --target clean
-Bill
_______________________________________________
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
