[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