Is the goal of add_library interface libraries to add the concept of
inherited build properties not dependent on the directory project
inheritance structure of CMake?
This is to say attach any and all cmake properties, flags, etc to a "dummy"
target that can then be used by other target to "inheri
So I have a "super build" CMake script that runs a series of
ExternalProject_Add() functions to execute builds of various third
party libraries and install them to a path relative to the parent
project's CMAKE_BINARY_DIR.
Once the parent project generation occurs, it is expected to do a
series of
On Thu, Aug 24, 2017 at 2:46 AM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
>
> Ok got it sorry to hear that certainly because, as soon as I hear
>> something that would be useful somehow I end up needing it the next day.
>> So sorry for us both.
>>
>> From what your are saying
Thanks for explaining, as usual your answers are making things much more clear.
When it's all said and done and considering everything we've discussed
up to this point, I'm fine with how you've architected the CMake
integration with Gradle. I think the way things function is perfectly
fine. My onl
Hello,
I use cmake 3.8.2 with visual studio 2013 64 bits.
I wanted to compile a thirdparty library using ExternalProject
When I do this, I meet errors: cmake is trying to read the download timestamp
in the wrong directory:
the thirdparty library id build in
${CMAKE_BINARY_DIR}/_dep/CoinMP-1.8.
Hi Martin,
You can have a look into the makefiles CMake generates for you inside of
your build directory.
Search for the failing file name there, e.g. do a find . -name Makefile
-exec grep -H 'm_material_mco_chg' {} \;
in the build directory.
Hope that helps, Cheers Volker
Am 24/08/2017 um
Dear Volker,
indeed the name of the file is replaced by "d". And I have no idea why. All the
files before run smoothly. Is there any point where I can get n idea how the
internal CMAKE commands are created?
Martin
--
Dr.-Ing. Martin Larcher
European Commission
Joint Research Centre, T.P. 480
Di
Hi,
Since upgrading to a recent CMake, the FLightGear build system is now reporting
this:
==
CMake Warning at utils/fgai/CMakeLists.txt:1 (add_executable):
Cannot generate a safe runtime search path for target fgai because there is
a cycle in the constraint graph:
dir 0
Am 24/08/2017 um 14:03 schrieb Volker Enderlein:
Am 24/08/2017 um 08:42 schrieb martin.larc...@ec.europa.eu:
*/usr/bin/cmake -E cmake_copy_f90_mod source/d
source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler*
Error copying Fortran module "source/d". Tried "source/D.mod" and
"source/d.m
Am 24/08/2017 um 08:42 schrieb martin.larc...@ec.europa.eu:
*/usr/bin/cmake -E cmake_copy_f90_mod source/d
source/CMakeFiles/epx.dir/d.mod.stamp Intel Fortran Compiler*
Error copying Fortran module "source/d". Tried "source/D.mod" and
"source/d.mod".
what CMakeLists.txt does issue this line? L
On Wed, Aug 23, 2017 at 9:57 PM, Robert Maynard
wrote:
> A quick scan of CMake source code shows that we don't have any
> references to gcc_eh anywhere. I way this could be occurring is
> through CMake detection of the implicit libraries that a compiler
> requires for each language. In particular
> Ok got it sorry to hear that certainly because, as soon as I hear
> something that would be useful somehow I end up needing it the next day.
> So sorry for us both.
>
> From what your are saying (and I will take your word for it) the CMake has
> a another problem in not implementing "inherited bu
12 matches
Mail list logo
