[CMake] External_Project_Add() and custom build configurations ?
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 ?
On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs 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
Re: [CMake] External_Project_Add() and custom build configurations ?
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 wrote:
> On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs 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 CMa
Re: [CMake] External_Project_Add() and custom build configurations ?
On Tue, Jul 5, 2011 at 12:02 PM, Glenn Coombs wrote:
> 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 wrote:
>
>> On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs 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
Re: [CMake] External_Project_Add() and custom build configurations ?
On 6 July 2011 17:27, David Cole 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:
/external_proj.vcproj
/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 /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
/external_proj/src/external_proj-build directory. But if cmake
had hooked the AfterClean event on external_proj and then called cmake
--build /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 wrote:
>
>> On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs wrote:
>>
>>> On 5 July 2011 17:13, David Cole 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, t
Re: [CMake] External_Project_Add() and custom build configurations ?
On Thu, Jul 7, 2011 at 7:36 AM, Glenn Coombs wrote: > On 6 July 2011 17:27, David Cole 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: > > /external_proj.vcproj > /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 /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 > /external_proj/src/external_proj-build directory. But if cmake > had hooked the AfterClean event on external_proj and then called cmake > --build /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 ?
On 7 July 2011 15:15, David Cole 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 ?
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 [options] [-- [native-options]]
Options:
= Project binary directory to be built.
--target = Build instead of default targets.
--config = For multi-configuration tools, choose .
--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
