[Cmake-commits] CMake branch, master, updated. v3.9.1-580-g9538d22

_VERSION_MINOR 9) -set(CMake_VERSION_PATCH 20170824) +set(CMake_VERSION_PATCH 20170825) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[CMake] Inherited Build Properties: Is this the intent of add_library Interface Libraries?

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

[CMake] Best practice for modifying search path for find_package()

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

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

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

Re: [CMake] CMake + Gradle for Android

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

[CMake] ExternalProject and Visual studio solutions

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

Re: [CMake] CMAKE Fortran - error while coping modules

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

Re: [CMake] CMAKE Fortran - error while coping modules

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

[CMake] Understanding constraint graph cycles

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

[Cmake-commits] CMake branch, release, updated. v3.9.1-17-g6fd0c72

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 6fd0c721158b51690ca9e7e9d34b82ef7e0f03ff (commit) via

[Cmake-commits] CMake branch, master, updated. v3.9.1-575-g797196c

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 797196c8a7d1a21d1551357f244daa23cf7c918f (commit) via

Re: [CMake] CMAKE Fortran - error while coping modules

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

Re: [CMake] CMAKE Fortran - error while coping modules

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?

Re: [cmake-developers] PRE_BUILD misconception

Am Donnerstag, 24. August 2017, 07:48:48 CEST schrieb Brad King: > On 08/23/2017 05:56 PM, Sebastian Holtermann wrote: > > It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen > > target more often than necessary (it could use PRE_BUILD instead). > > > > Let's assume a target

Re: [cmake-developers] Windows symbolic links handling

On 08/24/2017 03:19 AM, Manu wrote: > I have fixed it but I am struggling with the new policy. The > behaviour change goes into cmSystemTools::GetRealPath implementation > and SystemTools has no context, so I am not sure how to check the policy. The policy would have to be checked higher in the

Re: [cmake-developers] PRE_BUILD misconception

On 08/23/2017 05:56 PM, Sebastian Holtermann wrote: > It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen > target more often than necessary (it could use PRE_BUILD instead). > > Let's assume a target `B` that depends on > - a *GENERATED* file `FA` > - a linked library `LA` >

Re: [CMake] CMake, Mingw-w64 32 bit exception handling.

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

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

> 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

Re: [cmake-developers] Windows symbolic links handling

Hello, I have fixed it but I am struggling with the new policy. The behaviour change goes into cmSystemTools::GetRealPath implementation and SystemTools has no context, so I am not sure how to check the policy. Mimicking policy CMP0067 usage, I could create an old and a new version of

[CMake] CMAKE Fortran - error while coping modules

Dear all, I'm quite new in CMAKE. The compilation of our sources (EUROPLEXUS) under Windows is running very well but under Linux I get an error while cmake is copying the module files. For one particular file, cmake uses a wrong filename. See the two bold lines below. Any idea? Many thanks