[CMake] ExternalProject_Add() macro does not set CMAKE_COMPILER_IS_GNUCXX

[fkillus]

Thanks for your suggestion! I consider trying it soon.

On Wed, Jan 20, 2016 at 11:44 PM, Craig Scott <audiofanatic at gmail.com>
wrote:

>
> 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
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160121/58fff688/attachment.html>