[CMake] External_Project_Add() and custom build configurations ?
Bill Hoffman
bill.hoffman at kitware.com
Thu Jul 7 11:46:37 EDT 2011
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
More information about the CMake
mailing list