On Apr 11, 2013, at 11:27 AM, Braden McDaniel <[email protected]> wrote:

> On Apr 1, 2013, at 3:10 PM, Micha Hergarden <[email protected]> wrote:
> 
>> On 01-04-13 20:02, Braden McDaniel wrote:
>>> When mixing a CMake Visual Studio build that has ExternalProjects (that is, 
>>> via ExternalProject_Add) that use non-CMake makefile builds, how does one 
>>> resolve the mismatch between the *_<config> variables 
>>> (CMAKE_CXX_FLAGS_RELEASE, etc.)?
>>> 
>>> Specifically, how do I propagate the build flags in the *_<config> 
>>> variables down to the ExternalProject?  I can't seem to find a way in CMake 
>>> that will let me pick which variable to propagate (that is, 
>>> CMAKE_CXX_FLAGS_DEBUG when I'm building the Debug configuration, 
>>> CMAKE_CXX_FLAGS_RELEASE when building the Release configuration, etc.).
>>> 
>>> One option seems to be just to build the makefile-based ExternalProject 
>>> four times--one for each configuration CMake generates in its project 
>>> files.  But that, too, has a problem: what if the makefile-based 
>>> ExternalProject has a dependency on another ExternalProject with a CMake 
>>> build?
>>> 
>>> Are there any good solutions to these sorts of problems?
>>> 
>> 
>> In my project I've added wrappers for each stage:
>> 
>> PATCH_COMMAND "${CMAKE_CURRENT_BINARY_DIR}/patchwrapper"
>> CONFIGURE_COMMAND "${CMAKE_CURRENT_BINARY_DIR}/configurationwrapper"
>> BUILD_COMMAND "${CMAKE_CURRENT_BINARY_DIR}/buildwrapper"
>> INSTALL_COMMAND "${CMAKE_CURRENT_BINARY_DIR}/installwrapper"
>> 
>> These wrappers include a defaults file that I create from a defaults.in, 
>> using configure_file command. That way I can set flags and all kinds of 
>> build related variables. Although officially it's not recommended to use it 
>> in generic cmake based projects, it works quite well for me as I don't 
>> distribute my project. I just use the external projects to precompile some 
>> third party tooling.
> 
> 
> Thanks... I've made quite a bit of progress with this approach.
> 
> I'm attempting to use cmake -P for the wrapper script and I've been mostly 
> successful; though I've hit a bit of a speedbump that I'll outline in another 
> posting.


The problem was that I was setting CMAKE_ARGS in ExternalProject_Add in order 
to invoke my CMake script; but setting CMAKE_ARGS has the effect of calling 
CMake twice (once to configure, once to build).  The second call would result 
in an error.

Using BUILD_COMMAND to invoke CMake with my script has the desired effect.  
(Well, almost.  stdout from the build process now goes into a log file instead 
of being visible in the IDE's build output window.  But it'll do.)

-- 
Braden McDaniel
[email protected]

--

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

Reply via email to