Mixing non-CMake ExternalProjects using Visual Studio

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Mixing non-CMake ExternalProjects using Visual Studio

braden
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?

--
Braden McDaniel
[hidden email]

--

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
--
Braden McDaniel <braden@endoframe.com>
Reply | Threaded
Open this post in threaded view
|

Re: Mixing non-CMake ExternalProjects using Visual Studio

braden
On Apr 1, 2013, at 3:10 PM, Micha Hergarden <[hidden email]> 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.

--
Braden McDaniel
[hidden email]

--

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
--
Braden McDaniel <braden@endoframe.com>
Reply | Threaded
Open this post in threaded view
|

Re: Mixing non-CMake ExternalProjects using Visual Studio

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

> On Apr 1, 2013, at 3:10 PM, Micha Hergarden <[hidden email]> 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
[hidden email]

--

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
--
Braden McDaniel <braden@endoframe.com>