Re: [CMake] External_Project_Add() and custom build configurations ?

2011-07-07 Thread Glenn Coombs
On 6 July 2011 17:27, David Cole david.c...@kitware.com wrote:

 (Don't know if you meant to omit the CMake mailing list on that, or if that
 was on oversight Feel free to put my responses back on list if you
 wish.)


Oops, no I didn't mean to omit the mailing list.

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.


I'm not sure but wouldn't getting clean to work with Visual Studio require
changes to the generator code to add hooks in the vcproj files on either the
BeforeClean or AfterClean events ? As far as I can tell Visual Studio cleans
a project by deleting the files it thinks the project creates.  For normal
C/C++ projects this works as expected but for external projects the created
files are not known in the external project vcproj file.  However, they are
known in the subdirectory external project vcproj file.  To clarify, in my
case the external project has these 2 vcproj files:

buildDir/external_proj.vcproj
buildDir/external_proj/src/external_proj-build/myProjName.vcproj

The top level external_proj.vcproj file only contains a folder of
CMakeBuildRules which specify custom build commands for each of the
configure, build, install etc. steps.  When this top level project is built
it invokes cmake --build buildDir/external_proj/src/external_proj-build to
do the actual build.

If I clean external_proj then it has no idea what to delete under the
buildDir/external_proj/src/external_proj-build directory.  But if cmake
had hooked the AfterClean event on external_proj and then called cmake
--build buildDir/external_proj/src/external_proj-build --target clean then
that would get Visual Studio to clean the lower level myProjName.vcproj
which does know which files to clean because it is a normal C/C++ project.

The top level external_proj is the only one visible in Visual Studio.  The
lower level myProjName is not visble in Visual Studio but it is the only one
that knows how to do the clean.  If the top level one forwarded the clean to
it then everything would work.

I haven't checked but I suspect the same thing would work for the Makefile
generators.  The top level make clean would just call make clean on the
lower level makefile.

--
Glenn


On Wed, Jul 6, 2011 at 12:24 PM, David Cole david.c...@kitware.com wrote:

 On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs glenn.coo...@gmail.comwrote:

 On 5 July 2011 17:13, David Cole david.c...@kitware.com wrote:

 It is (intentionally) missing some functionality. You have not
 misunderstood.

 The general case of ExternalProject is completely arbitrary, although we
 do use reasonable default commands for cmake projects and configure/make
 projects as they are conventionally used... Since it's completely 
 arbitrary,
 we do not know if there is a 'clean' target at each level.


 Don't all projects configured using cmake have a clean target ?
 Certainly the makfiles on linux have a clean target, and the Visual Studio
 projects can all be individually cleaned.  It looks like
 ExternalProject_Add() already adds special case targets for test and install
 so that they end up calling:

 cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target test
 cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target
 install

 Would it not make sense to also add a special target for clean in the
 same manner ?


 It would make sense. But there is no --target clean on Visual Studio
 builds. Visual Studio has a clean mechanism, not a clean build target. So
 the API for doing a clean operation is inconsistent across all CMake
 generators. If it were consistent, I might be inclined to agree with you,
 but it's not.






 The best 'clean' is starting with an absolutely empty build tree, and
 running CMake and your build system from there.

 Since the best 'clean' is always going to be better than any
 target-based clean we could come up with, I wouldn't even attempt to add
 this functionality unless nearly everybody unanimously agreed that we 
 should
 have it. And only then if somebody writes a patch to provide it.


 On those grounds why do the cmake generated makefiles provide a clean
 target ?


 Because it was already here when I got here. :-) I'm pretty sure the
 primary motivation is because some projects have ridiculously long initial
 configuration times, and avoiding that by keeping the cache while blowing
 away the object files is useful to some... Personally, I'd rather see folks
 work on minimizing their configure times.




 Given that the infrastructure for cleaning is already present in cmake
 configured projects what reason is there to deliberately omit the code to
 call that funcionality ?


 As mentioned above, there is no consistent API that is convenient for
 calling from the ExternalProject code 

Re: [CMake] External_Project_Add() and custom build configurations ?

2011-07-07 Thread David Cole
On Thu, Jul 7, 2011 at 7:36 AM, Glenn Coombs glenn.coo...@gmail.com wrote:

 On 6 July 2011 17:27, David Cole david.c...@kitware.com wrote:

 (Don't know if you meant to omit the CMake mailing list on that, or if
 that was on oversight Feel free to put my responses back on list if you
 wish.)


 Oops, no I didn't mean to omit the mailing list.


 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.


 I'm not sure but wouldn't getting clean to work with Visual Studio require
 changes to the generator code to add hooks in the vcproj files on either the
 BeforeClean or AfterClean events ? As far as I can tell Visual Studio cleans
 a project by deleting the files it thinks the project creates.  For normal
 C/C++ projects this works as expected but for external projects the created
 files are not known in the external project vcproj file.  However, they are
 known in the subdirectory external project vcproj file.  To clarify, in my
 case the external project has these 2 vcproj files:

 buildDir/external_proj.vcproj
 buildDir/external_proj/src/external_proj-build/myProjName.vcproj

 The top level external_proj.vcproj file only contains a folder of
 CMakeBuildRules which specify custom build commands for each of the
 configure, build, install etc. steps.  When this top level project is built
 it invokes cmake --build buildDir/external_proj/src/external_proj-build to
 do the actual build.

 If I clean external_proj then it has no idea what to delete under the
 buildDir/external_proj/src/external_proj-build directory.  But if cmake
 had hooked the AfterClean event on external_proj and then called cmake
 --build buildDir/external_proj/src/external_proj-build --target clean then
 that would get Visual Studio to clean the lower level myProjName.vcproj
 which does know which files to clean because it is a normal C/C++ project.

 The top level external_proj is the only one visible in Visual Studio.  The
 lower level myProjName is not visble in Visual Studio but it is the only one
 that knows how to do the clean.  If the top level one forwarded the clean to
 it then everything would work.

 I haven't checked but I suspect the same thing would work for the Makefile
 generators.  The top level make clean would just call make clean on the
 lower level makefile.

 --
 Glenn


I'm sure that what you want to do is possible. I'm also sure that it's a
huge effort to get it to work with all CMake generators. It will also be
difficult to write a good test of the functionality.

Furthermore, I view it as largely unnecessary work...

...because a full file-system-level clean of deleting the entire build tree,
followed by a quick configure with CMake of the top level project, followed
by a regular build has largely the same net result with negligible
difference in total build time. If the difference in total build time is
non-negligible, and really annoying to somebody, then this huge effort may
well be worth it to them, at that point in time.

Right now, I'm not convinced the extra effort and extra complications in the
code are worthwhile additions to CMake.


Respectfully,
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] External_Project_Add() and custom build configurations ?

2011-07-07 Thread Glenn Coombs
On 7 July 2011 15:15, David Cole david.c...@kitware.com wrote:


 I'm sure that what you want to do is possible. I'm also sure that it's a
 huge effort to get it to work with all CMake generators. It will also be
 difficult to write a good test of the functionality.

 Furthermore, I view it as largely unnecessary work...

 ...because a full file-system-level clean of deleting the entire build
 tree, followed by a quick configure with CMake of the top level project,
 followed by a regular build has largely the same net result with negligible
 difference in total build time. If the difference in total build time is
 non-negligible, and really annoying to somebody, then this huge effort may
 well be worth it to them, at that point in time.

 Right now, I'm not convinced the extra effort and extra complications in
 the code are worthwhile additions to CMake.


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.

--
Glenn
___
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] External_Project_Add() and custom build configurations ?

2011-07-07 Thread Bill Hoffman

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


Re: [CMake] External_Project_Add() and custom build configurations ?

2011-07-05 Thread Glenn Coombs
This had me stumped for a while until I came across the -P command line
option to cmake.  I have now added a build command to my external project
like so:

ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external_proj
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${METASIM_INSTALL_DIR}
BUILD_COMMAND${CMAKE_COMMAND}
-DBUILD_TARGET:STRING=external_proj
-DBUILD_CONFIG:STRING=${CMAKE_CFG_INTDIR}
-P ${CMAKE_SOURCE_DIR}/ExProjectBuild.cmake
INSTALL_COMMAND
)

And then the ExProjectBuild.cmake file invokes cmake --build with the build
config changed appropriately when necessary:

message(In ExternalProjectBuild:)
message(BUILD_TARGET=${BUILD_TARGET})
message(BUILD_CONFIG=${BUILD_CONFIG})
message(CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR})

set (standardConfigsRelease Debug RelWithDebInfo MinSizeRel)

# map each build config in extraConfigs to the item in the same position in
extraConfigsMap
set (extraConfigsReleaseNoHidebugDebugPthreads
DebugOptimised)
set (extraConfigsMapReleaseDebugDebug)

list(FIND standardConfigs ${BUILD_CONFIG} pos)
if (pos LESS 0)
list(FIND extraConfigs ${BUILD_CONFIG} pos)
if (pos LESS 0)
message(FATAL_ERROR Unknown build config: ${BUILD_CONFIG})
endif()
list(GET extraConfigsMap ${pos} BUILD_CONFIG)
message(  MAPPED CONFIG: ${BUILD_CONFIG})
endif()

execute_process(
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR} --config ${BUILD_CONFIG}
)

Is that what you meant when you suggested using a custom BUILD_COMMAND ?  Or
was there a simpler way to do it ?

Also, I note that when I clean the external project in Visual Studio it
doesn't really clean it (i.e. after the clean a build still thinks there is
nothing to do).  And the clean doesn't invoke my ExProjectBuild script.

If I manually run cmake --build externalProjectDir --target clean from the
command line then it does clean the project properly.  Is
ExternalProject_Add() missing some functionality here, or have I
misunderstood something ?

--
Glenn


On 1 July 2011 18:01, David Cole david.c...@kitware.com wrote:

 On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs glenn.coo...@gmail.comwrote:

 I have just started using some externally supplied cmake projects in my
 cmake project.  To do this I added these lines to my top level
 CMakeLists.txt file:

 include(ExternalProject)

 ExternalProject_Add(external_proj
 PREFIX${CMAKE_BINARY_DIR}/external_proj
 SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
 CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
   -DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
 INSTALL_COMMAND
 )

 And that worked very well.  Inside Visual Studio when I build my project
 it automatically runs the cmake configure step for the external projects and
 builds them as well.  The problem I have just discovered is when using a
 build configuration other than the default ones.  I can build Debug and
 Release configurations fine.  My project also has a DebugOptimised
 configuration but the external projects don't.  When I try to build my
 project it fails to build the external projects.  I used build_command() to
 see what commands would be used to build each configuration and I can see
 the cause of the problem:

 Debug:  VCExpress.exe myProj.sln /build Debug  /project
 external_proj
 DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
 external_proj

 Is there a way to tell cmake how to map my build configurations onto those
 that an external project has ?  In this case I would like to build the
 external project as Debug when I am building my project as DebugOptimised.

 --
 Glenn


 ___
 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


 With Visual Studio builds, external projects get built (by default) with
 the same configuration as the outer project. If you want a different
 configuration built, then you will have to customize the BUILD_COMMAND. You
 can look in the source for ExternalProject.cmake to see how the default
 BUILD_COMMAND is constructed and go from there.

 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 

Re: [CMake] External_Project_Add() and custom build configurations ?

2011-07-05 Thread David Cole
On Tue, Jul 5, 2011 at 12:02 PM, Glenn Coombs glenn.coo...@gmail.comwrote:

 This had me stumped for a while until I came across the -P command line
 option to cmake.  I have now added a build command to my external project
 like so:


 ExternalProject_Add(external_proj
 PREFIX${CMAKE_BINARY_DIR}/external_proj
 SOURCE_DIR${CMAKE_SOURCE_DIR}/external_proj
 CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
 -DMETAGS_DIR=${METASIM_INSTALL_DIR}
 BUILD_COMMAND${CMAKE_COMMAND}
 -DBUILD_TARGET:STRING=external_proj
 -DBUILD_CONFIG:STRING=${CMAKE_CFG_INTDIR}
 -P ${CMAKE_SOURCE_DIR}/ExProjectBuild.cmake
 INSTALL_COMMAND
 )

 And then the ExProjectBuild.cmake file invokes cmake --build with the build
 config changed appropriately when necessary:

 message(In ExternalProjectBuild:)
 message(BUILD_TARGET=${BUILD_TARGET})
 message(BUILD_CONFIG=${BUILD_CONFIG})
 message(CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR})

 set (standardConfigsRelease Debug RelWithDebInfo MinSizeRel)

 # map each build config in extraConfigs to the item in the same position in
 extraConfigsMap
 set (extraConfigsReleaseNoHidebugDebugPthreads
 DebugOptimised)
 set (extraConfigsMapReleaseDebugDebug)

 list(FIND standardConfigs ${BUILD_CONFIG} pos)
 if (pos LESS 0)
 list(FIND extraConfigs ${BUILD_CONFIG} pos)
 if (pos LESS 0)
 message(FATAL_ERROR Unknown build config: ${BUILD_CONFIG})
 endif()
 list(GET extraConfigsMap ${pos} BUILD_CONFIG)
 message(  MAPPED CONFIG: ${BUILD_CONFIG})
 endif()

 execute_process(
 COMMAND ${CMAKE_COMMAND}
 --build ${CMAKE_BINARY_DIR} --config ${BUILD_CONFIG}
 )

 Is that what you meant when you suggested using a custom BUILD_COMMAND ?
 Or was there a simpler way to do it ?


Yes, that's what I meant. No, I can't think of a simpler/generic way to do
this. Only you can know the relationship between your customized configs and
the well-known configs...




 Also, I note that when I clean the external project in Visual Studio it
 doesn't really clean it (i.e. after the clean a build still thinks there is
 nothing to do).  And the clean doesn't invoke my ExProjectBuild script.

 If I manually run cmake --build externalProjectDir --target clean from
 the command line then it does clean the project properly.  Is
 ExternalProject_Add() missing some functionality here, or have I
 misunderstood something ?


It is (intentionally) missing some functionality. You have not
misunderstood.

The general case of ExternalProject is completely arbitrary, although we do
use reasonable default commands for cmake projects and configure/make
projects as they are conventionally used... Since it's completely arbitrary,
we do not know if there is a 'clean' target at each level.

The best 'clean' is starting with an absolutely empty build tree, and
running CMake and your build system from there.

Since the best 'clean' is always going to be better than any target-based
clean we could come up with, I wouldn't even attempt to add this
functionality unless nearly everybody unanimously agreed that we should have
it. And only then if somebody writes a patch to provide it.


HTH,
David




 --
 Glenn



 On 1 July 2011 18:01, David Cole david.c...@kitware.com wrote:

 On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs glenn.coo...@gmail.comwrote:

 I have just started using some externally supplied cmake projects in my
 cmake project.  To do this I added these lines to my top level
 CMakeLists.txt file:

 include(ExternalProject)

 ExternalProject_Add(external_proj
 PREFIX${CMAKE_BINARY_DIR}/external_proj
 SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
 CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
   -DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
 INSTALL_COMMAND
 )

 And that worked very well.  Inside Visual Studio when I build my project
 it automatically runs the cmake configure step for the external projects and
 builds them as well.  The problem I have just discovered is when using a
 build configuration other than the default ones.  I can build Debug and
 Release configurations fine.  My project also has a DebugOptimised
 configuration but the external projects don't.  When I try to build my
 project it fails to build the external projects.  I used build_command() to
 see what commands would be used to build each configuration and I can see
 the cause of the problem:

 Debug:  VCExpress.exe myProj.sln /build Debug  /project
 external_proj
 DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
 external_proj

 Is there a way to tell cmake how to map my build configurations onto
 those that an external project has ?  In this case I would like to build the
 external project as Debug 

[CMake] External_Project_Add() and custom build configurations ?

2011-07-01 Thread Glenn Coombs
I have just started using some externally supplied cmake projects in my
cmake project.  To do this I added these lines to my top level
CMakeLists.txt file:

include(ExternalProject)

ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
  -DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
INSTALL_COMMAND
)

And that worked very well.  Inside Visual Studio when I build my project it
automatically runs the cmake configure step for the external projects and
builds them as well.  The problem I have just discovered is when using a
build configuration other than the default ones.  I can build Debug and
Release configurations fine.  My project also has a DebugOptimised
configuration but the external projects don't.  When I try to build my
project it fails to build the external projects.  I used build_command() to
see what commands would be used to build each configuration and I can see
the cause of the problem:

Debug:  VCExpress.exe myProj.sln /build Debug  /project
external_proj
DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
external_proj

Is there a way to tell cmake how to map my build configurations onto those
that an external project has ?  In this case I would like to build the
external project as Debug when I am building my project as DebugOptimised.

--
Glenn
___
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] External_Project_Add() and custom build configurations ?

2011-07-01 Thread David Cole
On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs glenn.coo...@gmail.com wrote:

 I have just started using some externally supplied cmake projects in my
 cmake project.  To do this I added these lines to my top level
 CMakeLists.txt file:

 include(ExternalProject)

 ExternalProject_Add(external_proj
 PREFIX${CMAKE_BINARY_DIR}/external_proj
 SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
 CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
   -DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
 INSTALL_COMMAND
 )

 And that worked very well.  Inside Visual Studio when I build my project it
 automatically runs the cmake configure step for the external projects and
 builds them as well.  The problem I have just discovered is when using a
 build configuration other than the default ones.  I can build Debug and
 Release configurations fine.  My project also has a DebugOptimised
 configuration but the external projects don't.  When I try to build my
 project it fails to build the external projects.  I used build_command() to
 see what commands would be used to build each configuration and I can see
 the cause of the problem:

 Debug:  VCExpress.exe myProj.sln /build Debug  /project
 external_proj
 DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
 external_proj

 Is there a way to tell cmake how to map my build configurations onto those
 that an external project has ?  In this case I would like to build the
 external project as Debug when I am building my project as DebugOptimised.

 --
 Glenn


 ___
 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


With Visual Studio builds, external projects get built (by default) with the
same configuration as the outer project. If you want a different
configuration built, then you will have to customize the BUILD_COMMAND. You
can look in the source for ExternalProject.cmake to see how the default
BUILD_COMMAND is constructed and go from there.

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