[CMake] ExternalProject_Add() macro does not set CMAKE_COMPILER_IS_GNUCXX

Craig Scott audiofanatic at gmail.com
Wed Jan 20 17:44:28 EST 2016


> From: fkillus <fkillus at googlemail.com>
> To: cmake at cmake.org
> Cc:
> Date: Wed, 20 Jan 2016 18:41:26 +0100
> Subject: [CMake] ExternalProject_Add() macro does not set
> CMAKE_COMPILER_IS_GNUCXX
> I have been trying to compile Ogre [1] as external dependency with
> ExternalProject_Add(). In theory this should be straightforward since Ogre
> itself also uses CMake as buildsystem. However, in the process I
> encountered the following problem:
>

> Ogre checks the value of the CMAKE_COMPILER_IS_GNUCXX variable in some
> places (e.g. [2]). I am running Linux and compiling with g++ and everything
> works fine if I manually configure Ogre with cmake or cmake-gui.
> Unfortunately, after wrapping everything inside ExternalProject_Add(), the
> CMAK_COMPILER_IS_GNUCXX variable is no longer being set correctly.
>
> A simple workaround is to manually set this variable, i.e.:
>
>  ExternalProject_Add(
>     ogre
>     URL https://bitbucket.org/sinbad/ogre/get/v1-9-0.zip
>     CMAKE_ARGS
>       -DCMAKE_INSTALL_PREFIX=${DEPENDENCIES_OUTPUT_DIR}
>       -DCMAKE_COMPILER_IS_GNUCXX=${CMAKE_COMPILER_IS_GNUCXX}   # workaround
>   )
>
> This works, but I'm uncertain if this should be necessary. Is this a bug
> or a feature?
>
>
> [1] https://bitbucket.org/sinbad/ogre
> [2]
> https://bitbucket.org/sinbad/ogre/src/0d580c7216abe27fafe41cb43e31d8ed86ded591/CMake/Utils/OgreConfigTargets.cmake?at=default&fileviewer=file-view-default#OgreConfigTargets.cmake-277
>
>

Since Ogre is a CMake project, you may find the technique described at the
following link useful. It uses GoogleTest as its example, but it should
also apply to your situation. The approach uses ExternalProject only to
download the source at CMake time. It then pulls it into your normal build
via add_subdirectory(), so it gets all the same compiler details, etc. as
your main build because it IS part of your main build.

http://crascit.com/2015/07/25/cmake-gtest/

I am not familiar with Ogre's build, so I can't comment on whether it will
play nice if pulled into a parent build like this, but it's worth a try.
The article links to a github repo which provides a fully generalised
implementation you should be able to use out of the box.


-- 
Craig Scott
Melbourne, Australia
http://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160121/8ea11635/attachment.html>


More information about the CMake mailing list