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

[Kitware Robot]

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  9538d22d955a0b101548019003f2d5c7ba833d77 (commit)
  from  c7c639f2f363b6918ac13daea214cea56035e0aa (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9538d22d955a0b101548019003f2d5c7ba833d77
commit 9538d22d955a0b101548019003f2d5c7ba833d77
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Aug 25 00:01:07 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Aug 25 00:01:07 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fdfb7a8..b61098f 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_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/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Brian Davis]

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 "inherit" the build config
of the "dummy" target.

Can it be used to get around the inherent folder inheritance mechanism in
CMake?

Does it support all properties, flags, defs?  Say for example:

from: https://cmake.org/pipermail/cmake/2017-August/066122.html

add_library(blah INTERFACE)
set_property(TARGET blah PROPERTY SUFFIX ".mxe")
set_property(TARGET blah PROPERTY CXX_STANDARD 14)
set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")

without:

CMake Error at CMakeLists.txt:4 (set_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "SUFFIX" is not allowed.

oh... I know my bad... lets try set_target_properties:

set_target_properties(
blah
PROPERTIES
SUFFIX ".mxe"
CXX_STANDARD 14
INSTALL_RPATH "@loader_path/whatever"
)

without say:


CMake Error at CMakeLists.txt:20 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "SUFFIX" is not allowed.

CMake Error at CMakeLists.txt:20 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "CXX_STANDARD" is not allowed.

CMake Error at CMakeLists.txt:20 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "INSTALL_RPATH" is not allowed.

One might want to say create a template (add_project Interface Library) for
all MATLAB mex libraries where say SUFFIX is .mex (above is example from
others) but I would like same functionality for MATLAB Mex plugins then
have plugin target inherit build props via  say:

add_library( mex_interface INTERFACE )
set_target_properties(
mex_interface
PROPERTIES
SUFFIX ".mex64"
LINK_FLAGS /export:mex_function
)

target_link_libraries(
   targ
   mex_interface).

But what do I get:

CMake Error at CMakeLists.txt:31 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "SUFFIX" is not allowed.

CMake Error at CMakeLists.txt:31 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "LINK_FLAGS" is not allowed.


Hmmm I know lets look up whitelisted in CMake doc surely that will tell me
something about INTERFACE whitlisted properties.

https://cmake.org/cmake/help/latest/search.html?q=whitelisted_keywords=yes=default

Yep... bubkis as expected... in true CMake style.

Since I have the CMake 3.9 source checkout as it is the only way these days
to figure out what CMake does/does not..  I search that for whitelist and
I'll certainly report back on how that goes.


In reading:

https://cmake.org/cmake/help/latest/command/add_library.html?highlight=interface

"An INTERFACE library target does not directly create build output, though
it may have properties set on it and it may be installed, exported and
imported. Typically the INTERFACE_* properties are populated on the
interface target using the commands:"

correction: "it may have WHITELISTED properties that we are not going to
document what they are cuz it's like super secret ... good luck!, but if
you can figure out what they are by trial and error and using eclipse ide
search on the checked out source tree and set on it and it may be
installed, exported and imported."

Huh a library that is just a interface which is not actually a library and
is not a build output... could a worse term "library" been used.  how about
add_interface or add_config or some such not library which I can understand
as an easy hack as libs are consumable by both exe's and libs, but
really... library?  Are command name additions at a premium in CMake?

So I'll ask again what is the intent of add_project interface libraries?

I am getting a pretty good idea what it's not... well i guess better idea
what it isn't once find that whitelist.
-- 

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

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

[Robert Dailey]

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 find_package() commands to locate the packages installed by
the previous super build.

What is the best way to intercept the find_package() search paths to
prioritize searching to the custom relative root directory managed by
the super build? Based on the documentation for find_package()[1],
seems like CMAKE_PREFIX_PATH might be the best way (set it as a normal
variable, not a cache variable) inside the CMake scripts prior to the
find_package() invocations (which are done indirectly by other CMake
scripts I do not manage and cannot change). Although, the usage intent
for CMAKE_PREFIX_PATH seems to be documented differently than how I
plan to use it.

Any advice?

[1]: https://cmake.org/cmake/help/v3.6/command/find_package.html
-- 

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

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

[Brian Davis]

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 (and I will take your word for it) the CMake
>> has a another problem in not implementing "inherited build properties"
>> correctly.  That is of course if that is what CMake is after with
>> add_library( targ INTERFACE) in the first place.
>>
>>
> I think that there is just no mechanism for "inherited build properties".
> From the docs (https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.
> 7.html#interface-libraries), INTERFACE targets seems to be meant for
> header-only libraries.
>
> The "inheritance" mechanism in CMake is mainly setting variables in a
> given folder, but this is imho not flexible enough, and leads to problems
> when you want to use your library as a subfolder of another since you don't
> have an easy way to overwrite "child" variables from a parent scope unless
> the child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags
> ${CMAKE_CXX_FLAGS}") every time.
>
>

Yes absolutely the inheritance mech is folder based and is the very
problem.  This is the very problem with LINK_DIRECTORIES,
INCLUDE_DIRECTORIES, and flags I initial had in 2009 and from from the
current state of things 8 years later it appears that not much is changed.
I have been able to use the interface mech to get around what was my
use-case for my "project/config" macros, but from what your saying I will
only get so far before the CMake design rope around my ankle staked out at
the start line ends in me falling flat on my face.

It is refreshing to see there is at least someone else out there that
understands this core problem in CMake, wish Kitware did, Boost.Build
had/has no such problem.  We as humans learn form our mistakes... over and
over again... every generation... sadly they are the same mistakes.  You
state IMHO, but there are no opinions involved on my end... it is simply a
FACT that CMake design is flawed.  Personally I am way past opinions.  It
appears that I must begin Honey Badgering ;-) the devs until this is
finally fixed or just fix it myself.

If you have some CMake code that you now does now work say in a test proj I
can test to see what fully does not work then I can add this to my issues
when I begin the feature request / request for sanity.

Also I will likely post another inherited build props specific post so that
these problems and be discussed specifically and can be refereed to by devs
for the why.

I don't know if you have a current macro end-around solution, but if you
want I could post my project/config macros on git hub.  You would likely
have to mod those to get add_project_configuration  to accept all your
build props to be inherited.  Ideally I long for a core solution in CMake
and thought / hoped I had it with interface.  Thanks for crushing my hopes
and  dreams :-).


At one time I did have a compiler_config in my code so your needs for CXX
Flags may just work with below (it's commented out in my current proj, but
the place holder is still there)

add_project_configuration(
compiler_config
#CXX_FLAGS_INIT
#"/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR "
#CXX_FLAGS_DEBUG
#"/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od /Gm "
#CXX_FLAGS_DEBUG_INIT
#"/D_DEBUG ${THREAD_DEBUG_OPT} /Zi /Ob0 /Od "
#
#C_FLAGS_DEBUG
#"/D_DEBUG /MDd  /Zi  /Ob0 /Od  "
#C_FLAGS_DEBUG_INIT
#"/D_DEBUG /MDd /Zi  /Ob0 /Od "
#
#CXX_FLAGS_MINSIZEREL_INIT
#"/MD /O1 /Ob1 /D NDEBUG"
#CXX_FLAGS_RELEASE_INIT
#"/MD /O2 /Ob2 /D NDEBUG"
#CXX_FLAGS_RELWITHDEBINFO_INIT
#"/MD /Zi /O2 /Ob1 /D NDEBUG"
#
#C_FLAGS_INIT
#"/DWIN32 /D_WINDOWS /W3 /Zm1000"
#C_FLAGS_MINSIZEREL_INIT
#"/MD /O1 /Ob1 /D NDEBUG"
#C_FLAGS_RELEASE_INIT
#"/MD /O2 /Ob2 /D NDEBUG"
#C_FLAGS_RELWITHDEBINFO_INIT
#"/MD /Zi /O2 /Ob1 /D NDEBUG"
## the following line should break the build when it is working!! Right
now it is not as all FLAGS are not working.
#C_STANDARD_LIBRARIES_INIT
#"kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib mylib.lib"
#COMPILE_FLAGS /DGOOP_123
LINKER_LANGUAGE
CXX
)

Then the config props can be inherited as:

add_project_library(
GP_Loader
INHERIT_CONFIGURATIONS
compiler_config
mex_config
utility_config
boost_config
CPP_SOURCES
GP_Loader.cpp
${GP_LINK}
INSTALL_DIRECTORIES
#${CMAKE_CURRENT_SOURCE_DIR}
bin
${TOP}/source/Matlab/lib
LIB_SUFFIX
${MEX_LIB_EXT}
)

Certainly much less verbose that vanilla CMake goop.  If interested let me
know, but like I said may require some work to get them to do what you need
as 

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

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 only concern is with a (should I say minor?) implementation
detail: Trying to promote CMAKE_BINARY_DIR sharing where feasible to
do so. Like I mentioned earlier, I believe that the code-behind for
"externalNativeBuild" logic should detect when two "path" files refer
to the same physical CMakeLists.txt file within the same build
configuration and variant, and if true, reuse/share the same
CMAKE_BINARY_DIR instead of generating another one. This seems safe to
me since the only difference is possibly which targets get invoked.
Optimistically, the best case scenario here is that the 2nd
externalNativeBuild has to build nothing and just grab *.so files
already built by the first externalNativeProject (so long as both
point to the same "path" file on filesystem).

Whether or not you decide to specify the "path" at the common ancestor
build.gradle (to make managing the configuration in gradle easier
since the properties will be transitive) or keep it as it is (require
"path" at each leaf build.gradle), you can still check if the same
physical CMakeLists.txt file is being used between multiple leaf
gradle build files.

If ccache is capable of reading build cache between multiple CMake
binary dirs, I think it may solve some aspects of this problem: In
particular, it might solve the build performance problems (you'd still
be building the same libs only once, even across separate
CMAKE_BINARY_DIR, if I understand correctly). But it does not solve
other issues: In particular, custom_target or custom_command logic
that depends on custom timestamp file or caching logic (like, checking
if files already exist in CMAKE_BINARY_DIR, and if not, download them,
install them, etc. (ExternalProject_Add is a prime example)). Also
ccache won't reduce the disk space consumption that would exist due to
having multiple CMAKE_BINARY_DIR instead of consolidating and sharing
them.

Sorry if I'm just repeating myself, but I'm just trying to summarize
my thoughts. The situation is complex so I want to make sure I am not
leaving out any details for when you do finally discuss this
internally.

Thanks and let me know how things end up after your C++ meeting!

On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher  wrote:
> By gradle module projects, I just mean the leaf build.gradle files as
> opposed to the root build.gradle. By configurations, I mean Build Types
> (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I
> will use the term "variant" rather than "configuration" to be precise. See
> this write-up on build variants:
>
> https://developer.android.com/studio/build/build-variants.html#build-types
>
> This build matrix is constructed at the leaf build.gradle level. Native
> build in gradle allows you to set C/C++ flags individually for each variant
> so that you can define compiler flags (for example, -DFREE_VERSION).
>
> One thing to notice at this stage is that the same CMake target may be built
> with different compiler flags across different projects, build types, and
> product flavors. So in the general case, build outputs won't be the same.
>
> You asked which targets build when specifying path. By default, we build all
> targets that produce an .so. You can override this by setting
> externalNativeBuild.cmake.targets. For example,
>
> paid {
>   ...
>   externalNativeBuild {
> cmake {
>   ...
>   targets "native-lib-paid"
> }
>   }
> }
>
> As for your last question, the model we generally see used is that the main
> CMakeLists.txt is next to the leaf build.gradle such that this
> CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though
> they may share common dependencies and settings). Otherwise, multiple APK
> projects would perform pretty much similar to yours--they would build
> targets per-leaf project and not share build outputs. As far as I can see
> your organization is just as valid so long as you only build the targets you
> need.
>
> Regarding native dependencies between java projects. We generally try to
> avoid making the CMake build depend on the gradle build (you should be able
> to replicate the CMake build from the command-line if you set the right
> flags). At the moment I don't see a way we could make things better without
> violating that tenet but that could be lack of imagination on my part.
>
> We'll definitely be discussing this use case at our next C++ meeting and
> I'll also be checking for myself whether ccache will work in this CMake
> scenario. If ccache does work it seems like the natural level at which to
> fold identical builds.
>
>
>
> On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey 

[CMake] ExternalProject and Visual studio solutions

[ycollette . nospam]

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.3/Debug

But in the directory, I also see a 

${CMAKE_BINARY_DIR}/_dep/CoinMP-1.8.3/$(Configuration)

And cmake is looking at the download timestamp in the debug directory, but it's 
in the $(Configuration).


How can I manage correctly the value of CMAKE_CFG_INTDIR in an ExternalProject ?


I put here the part of code I use to compile this thirdparty lib:

# #
# ===>CoinMP
# #

if (KL_ENABLE_DOWNLOAD_COINMP)
  set(COINMP_VERSION "1.8.3")
  set(COINMP_URL 
"http://www.coin-or.org/download/source/CoinMP/CoinMP-${COINMP_VERSION}.zip;)

  set(COINMP_COMPILATION_OPTIONS " -fPIC 
-DCOIN_COMPILE_STATIC=${KL_COMPILE_STATIC}")
  set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_COMPILE_COVERAGE=${KL_COMPILE_COVERAGE}")
  set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_COMPILE_PROFILE=${KL_COMPILE_PROFILE}")
  set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_COMPILE_PROFILE_VALGRIND=${KL_COMPILE_PROFILE_VALGRIND}")
  set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_COMPILE_LTO=${KL_COMPILE_LTO}")
  set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_COMPILE_WHOPR=${KL_COMPILE_WHOPR}")
  if (WIN32)
set(COINMP_COMPILATION_OPTIONS "${COINMP_COMPILATION_OPTIONS} 
-DCOIN_ENABLE_DOWNLOAD_PTHREAD_WIN32=ON")
  endif ()
  
  set(COINMP_InstallDir 
"${EP_InstallDir}/CoinMP-${COINMP_VERSION}/${CMAKE_CFG_INTDIR}/")

  if (WIN32)
ExternalProject_Add(EP_CoinMP
PREFIX${COINMP_InstallDir}
DEPENDS   ${COINMP_LAPACK_DEPENDS}
URL   ${COINMP_URL}
UPDATE_COMMAND""
PATCH_COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP/ ${COINMP_InstallDir}/src/EP_CoinMP/ &&
  ${CMAKE_COMMAND} -E copy 
${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP.h 
${COINMP_InstallDir}/src/EP_CoinMP/CoinMP/src/ &&
  ${CMAKE_COMMAND} -E make_directory 
${COINMP_InstallDir}/src/EP_CoinMP/build/
CONFIGURE_COMMAND ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} 
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} 
-DCMAKE_INSTALL_PREFIX=${EP_InstallDir}/install/ -DCOIN_HAS_ABC=${KL_USE_ABC} 
-DCOIN_ABC_LEVEL=${KL_ABC_LEVEL} ${COINMP_COMPILATION_OPTIONS} 
-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} 
${EP_COMPILER} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -G 
${CMAKE_GENERATOR} ..
BUILD_COMMAND ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} --build . --config 
${CMAKE_CFG_INTDIR}
INSTALL_COMMAND   ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} --build . --config 
${CMAKE_CFG_INTDIR} --target install
   )
  else ()
ExternalProject_Add(EP_CoinMP
PREFIX${COINMP_InstallDir}
DEPENDS   ${COINMP_LAPACK_DEPENDS}
URL   ${COINMP_URL}
UPDATE_COMMAND""
PATCH_COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_SOURCE_DIR}/deps/Coin/CoinMP/ ${COINMP_InstallDir}/src/EP_CoinMP/ &&
  ${CMAKE_COMMAND} -E make_directory 
${COINMP_InstallDir}/src/EP_CoinMP/build/
CONFIGURE_COMMAND ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_COMMAND} 
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} 
-DCMAKE_INSTALL_PREFIX=${EP_InstallDir}/install/ -DCOIN_HAS_ABC=${KL_USE_ABC} 
-DCOIN_ABC_LEVEL=${KL_ABC_LEVEL} ${COINMP_COMPILATION_OPTIONS} 
-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS} -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} 
${EP_COMPILER} -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -G 
${CMAKE_GENERATOR} ..
BUILD_COMMAND ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_MAKE_PROGRAM}
INSTALL_COMMAND   ${CMAKE_COMMAND} -E chdir 
${COINMP_InstallDir}/src/EP_CoinMP/build ${CMAKE_MAKE_PROGRAM} install
   )
  endif ()
endif ()

# #
# <===CoinMP
# #

Best regards,

YC
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware 

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

[Volker Enderlein]

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 16:17 schrieb martin.larc...@ec.europa.eu:

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
Directorate for Space, Security and Migration
Safety and Security of Buildings
I-21027 Ispra (VA) Italy
Phone: +39-0332-789563


From: Volker Enderlein [volker.enderl...@ifm-chemnitz.de]
Sent: 24 August 2017 14:26
To: LARCHER Martin (JRC-ISPRA); cmake@cmake.org
Subject: 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
"source/d.mod".

what CMakeLists.txt does issue this line? Looks to me like a "*d
source/*" was creeping into the middle of the string. I didn't found
the command looking at the two files you provided. Especially the command

*/usr/bin/cmake -E cmake_copy_f90_mod*

is of interest.

Cheers Volker



It rather seems that "m_material_mco_chg" is replaced wth a "d"


Cheers Volker

--



--

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

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

[Martin.LARCHER]

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
Directorate for Space, Security and Migration
Safety and Security of Buildings
I-21027 Ispra (VA) Italy
Phone: +39-0332-789563


From: Volker Enderlein [volker.enderl...@ifm-chemnitz.de]
Sent: 24 August 2017 14:26
To: LARCHER Martin (JRC-ISPRA); cmake@cmake.org
Subject: 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
>> "source/d.mod".
>
> what CMakeLists.txt does issue this line? Looks to me like a "*d
> source/*" was creeping into the middle of the string. I didn't found
> the command looking at the two files you provided. Especially the command
>
> */usr/bin/cmake -E cmake_copy_f90_mod*
>
> is of interest.
>
> Cheers Volker
>
>

It rather seems that "m_material_mco_chg" is replaced wth a "d"


Cheers Volker

--

-- 

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

[CMake] Understanding constraint graph cycles

[James Turner]

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 is [/home/jenkins/workspace/FlightGear/dist/lib64]
  dir 1 must precede it due to runtime library [libosgText.so.130]
dir 1 is [/home/jenkins/workspace/SimGear/dist/lib64]
  dir 0 must precede it due to runtime library [libosgText.so.130]

  Some of these libraries may not be found correctly.
==


I can guess various dumb things I might have done to cause this, but can anyone 
give me some context? This is about rpath setting in the executables? 

SimGear is a helper library for FlightGear, build as static libs, and imported 
into FlightGear directly. SimGear and FlightGear both depend on OpenSceneGraph, 
and on our buiuld server (but not commonly in real life) Simgear and FlightGear 
are being configured with different install prefixes (that’s the 
/home/jenkins/workspace/dist/lib64 part)

Again rather than making ad-hoc changes to fix this, I’d like a bit more 
understanding about what is intended here, if anyone can suggest it.

All this code is publicly visible on SourceForge BTW:

https://sourceforge.net/p/flightgear/_list/git?source=navbar

Kind regards,
James
-- 

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

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

[Kitware Robot]

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  de9840d1b89481132ee128715506f6aee9d0277c (commit)
  from  02645aa6aec748a1f3ea24715b3bd03465ae4835 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/CMakeDetermineCompilerId.cmake |1 +
 1 file changed, 1 insertion(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Kitware Robot]

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  65ca67cef19bae85c4fd3582b474e9f95d3c9eb1 (commit)
   via  94299c496d54d037db35575447b011c6c8a35b0a (commit)
   via  061b4f24be8281a1504f6993602d79b61b862d6d (commit)
   via  efd0c013373f99e1e45310e24fced72d439d4adf (commit)
   via  90a34ff79196c90b64ab16066f957e51a78a7375 (commit)
   via  6756b552eedbe3f2185e02638701c11cd5799b86 (commit)
   via  fa114e7d708b76f33878f6f82a6c2a2e50c1c10f (commit)
   via  e66e8e891454b4addcb7dbd57a8bdc5eeaf7bff3 (commit)
  from  fe19fda2aa2595622c463fccaa8b36a91e4521c4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=797196c8a7d1a21d1551357f244daa23cf7c918f
commit 797196c8a7d1a21d1551357f244daa23cf7c918f
Merge: 65ca67c efd0c01
Author: Brad King 
AuthorDate: Thu Aug 24 13:34:03 2017 +
Commit: Kitware Robot 
CommitDate: Thu Aug 24 09:34:43 2017 -0400

Merge topic 'vs-sdk-refs'

efd0c013 VS: Fix VS_SDK_REFERENCES when target is not a Windows 10 app

Acked-by: Kitware Robot 
Merge-request: !1166


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65ca67cef19bae85c4fd3582b474e9f95d3c9eb1
commit 65ca67cef19bae85c4fd3582b474e9f95d3c9eb1
Merge: 94299c4 fa114e7
Author: Brad King 
AuthorDate: Thu Aug 24 13:33:38 2017 +
Commit: Kitware Robot 
CommitDate: Thu Aug 24 09:34:22 2017 -0400

Merge topic 'boost-1.65'

fa114e7d FindBoost: Add Boost 1.65 dependencies
e66e8e89 BoostScanDeps: Special case python and numpy and variants

Acked-by: Kitware Robot 
Merge-request: !1172


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94299c496d54d037db35575447b011c6c8a35b0a
commit 94299c496d54d037db35575447b011c6c8a35b0a
Merge: 061b4f2 90a34ff
Author: Brad King 
AuthorDate: Thu Aug 24 13:33:18 2017 +
Commit: Kitware Robot 
CommitDate: Thu Aug 24 09:33:55 2017 -0400

Merge topic 'ninja-gfortran-fpreprocessed'

90a34ff7 Ninja: Fix references to source files in gfortran diagnostics

Acked-by: Kitware Robot 
Merge-request: !1146


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=061b4f24be8281a1504f6993602d79b61b862d6d
commit 061b4f24be8281a1504f6993602d79b61b862d6d
Merge: fe19fda 6756b55
Author: Brad King 
AuthorDate: Thu Aug 24 13:32:46 2017 +
Commit: Kitware Robot 
CommitDate: Thu Aug 24 09:33:24 2017 -0400

Merge topic 'ipo-test-output'

6756b552 Tests: Print more info on CheckIPOSupported test failure

Acked-by: Kitware Robot 
Merge-request: !1177


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=efd0c013373f99e1e45310e24fced72d439d4adf
commit efd0c013373f99e1e45310e24fced72d439d4adf
Author: Roc Ramon 
AuthorDate: Mon Aug 21 09:08:37 2017 -0400
Commit: Brad King 
CommitDate: Wed Aug 23 15:43:46 2017 -0400

VS: Fix VS_SDK_REFERENCES when target is not a Windows 10 app

Close the `` element whenever it is opened.

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index e1a0c83..35b7350 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -3698,10 +3698,10 @@ void 
cmVisualStudio10TargetGenerator::WriteSDKReferences()
 this->WriteSingleSDKReference("WindowsIoT", iotExtensionsVersion);
   }
 }
+  }
 
-if (hasWrittenItemGroup) {
-  this->WriteString("\n", 1);
-}
+  if (hasWrittenItemGroup) {
+this->WriteString("\n", 1);
   }
 }
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90a34ff79196c90b64ab16066f957e51a78a7375
commit 90a34ff79196c90b64ab16066f957e51a78a7375
Author: Raul Laasner 
AuthorDate: Wed Aug 16 14:12:35 2017 -0400
Commit: Brad King 
CommitDate: Wed Aug 23 15:32:44 2017 -0400

Ninja: Fix references to source files in gfortran diagnostics

The Ninja generator preprocesses and compiles separately for Fortran.
When compiling, tell gfortran that the source is already preprocessed so
that it will honor the `# ` directives when producing diagnostics
messages.

Fixes: #17160

diff --git a/Modules/Compiler/GNU-Fortran.cmake 
b/Modules/Compiler/GNU-Fortran.cmake

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

[Volker Enderlein]

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.mod".


what CMakeLists.txt does issue this line? Looks to me like a "*d 
source/*" was creeping into the middle of the string. I didn't found 
the command looking at the two files you provided. Especially the command


*/usr/bin/cmake -E cmake_copy_f90_mod*

is of interest.

Cheers Volker




It rather seems that "m_material_mco_chg" is replaced wth a "d"


Cheers Volker

--

--

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

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

[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.mod".


what CMakeLists.txt does issue this line? Looks to me like a "*d 
source/*" was creeping into the middle of the string. I didn't found the 
command looking at the two files you provided. Especially the command


*/usr/bin/cmake -E cmake_copy_f90_mod*

is of interest.

Cheers Volker


--

--

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

Re: [cmake-developers] PRE_BUILD misconception

[Sebastian Holtermann]

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 `B` that depends on
> > 
> >  - a *GENERATED* file `FA`
> >  - a linked library `LA`
> >  - a utility target `TA` (via `add_dependencies()`)
> > 
> > Using the VS generator, will `FA`, `LA` and `TA` be built completely
> > before
> > target B executes it's PRE_BUILD?
> 
> Target-level dependencies will be completely finished, including their
> POST_BUILD if any, before the PRE_BUILD of a dependent target begins.
> In your list above, `LA` and `TA` will definitely be built before `B`
> starts.  For the generated file `FA`, it depends whether the custom
> command is attached to `B` or not.  If it is inside `B` then it won't
> generate until after PRE_BUILD is done.

Okay, thanks.
That will help to fix https://gitlab.kitware.com/cmake/cmake/issues/17205

-Sebastian

-- 

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-developers

Re: [cmake-developers] Windows symbolic links handling

[Brad King]

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 stack and used to
choose alternative implementations.

> Mimicking policy CMP0067 usage, I could create an old and a new version
> of GetRealPath and check for the policy prior calling it all along the code.
> On the other hand, I could pass the policy status as a parameter to every
> GetRealPath call. Which is the proper way?

Likely a second API would be needed.  The KWSys GetRealPath could be
taught to handle symlinks on Windows.  If it turns out a policy is
needed then a cmSystemTools:: alternative in CMake only could be added.

> To perform a pull request, should I previously open an issue about
> this or it is enough with the discusion here in the mailing list.

For reference, this issue has been opened:

  https://gitlab.kitware.com/cmake/cmake/issues/17206

I think we can try this without a policy first.

Thanks,
-Brad
-- 

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-developers

Re: [cmake-developers] PRE_BUILD misconception

[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 `B` that depends on
>  - a *GENERATED* file `FA`
>  - a linked library `LA`
>  - a utility target `TA` (via `add_dependencies()`)
> 
> Using the VS generator, will `FA`, `LA` and `TA` be built completely before
> target B executes it's PRE_BUILD?

Target-level dependencies will be completely finished, including their
POST_BUILD if any, before the PRE_BUILD of a dependent target begins.
In your list above, `LA` and `TA` will definitely be built before `B`
starts.  For the generated file `FA`, it depends whether the custom
command is attached to `B` or not.  If it is inside `B` then it won't
generate until after PRE_BUILD is done.

PRE_BUILD in VS means "if any files associated with this .vcxproj
are about to be built due to updated dependencies or missing outputs,
then run this pre-build command first".

-Brad
-- 

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-developers

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

[Arne Kjetil Andersen]

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 it could be that C code for
> mingw by default uses gcc_eh while C++ doesn't. The culprit could also
> be a FindPackage* you are using.
>

Hi Robert and thanks for your reply. Yes I also did a scan of the cmake
source code before sending the mail to the mailing list, and found no
reference to gcc_eh. But I do find reference to that in the CMakeOutput.log
file, and it seems to come from detection of implicit libraries. So based
on this i started by removing all 3rd party libraries in my project and
thought of adding one by one until the -lgcc_eh appeared in the
linklibs.rsp, and you are right, adding proj.4 3rd party library to the
build system seems to result in -lgcc_eh being added... Now to figure out
how to prevent that from occurring in linklibs.rsp file for the test
application that does not even use that particular 3rd party library.

Thanks again for pointing me in the right direction.

Best Regards,
Arne Kjetil Andersen


>
> On Wed, Aug 23, 2017 at 4:55 AM, Arne Kjetil Andersen 
> wrote:
> > Greetings.
> >
> > I'm a developer on a fairly large project where I'm using CMake version
> > 3.9.1
> >
> > I primarily work on linux, but also cross compiles for windows using
> > Mingw-w64 on my linux box.
> >
> > I have encountered an issue which I'm having some trouble figuring out.
> > Running through some of my tests where an exception is thrown (on
> purpose)
> > the 32 bit version compiled with Mingw-w64-g++ version 7.1.1 just calls
> > terminate even though there are try catch blocks. Now mind you, this all
> > works fine on the native linux compiled version of my tests, and also
> the 64
> > bit windows version compiled with Mingw-w64-g++ version 7.1.1.
> >
> > Going through all the projects CMakeLists.txt I could not find any reason
> > for this behavior, but tried to add -fexceptions as a compiler option in
> the
> > top most CMakeLists.txt file for the 32 bit mingw-w64 compiler.
> > Unfortunately this made no difference.
> >
> > So investigating some more I took a look at the linklibs.rsp file
> generated
> > for that particular test executable, and noticed this entry:
> > -lgcc_eh -lgcc_eh
> >
> > (yes it's twice, but that is not the issue, although that might be a
> cmake
> > bug?).
> > (also note - this option is also present for the 64 bit build files for
> > mingw-w64, but there it works as expected).
> >
> > Now, removing those two library link options from the linklibs.rsp file
> > makes the 32 bit windows version of test application work as expected. I
> am
> > not sure what libgcc_eh.a actually does (tried searching for some
> > information, but had little luck actually figuring that out), but
> clearly it
> > has something to do with exception handling.
> >
> > Now I figured I would create a small minimal example that would reproduce
> > this issue outside my projects source tree. So basically created a small
> > program that throws an exception, and catches that. Created a
> CMakeLists.txt
> > file with the same general options as my farily large project, and had
> cmake
> > generate the build files for 32 bit mingw-w64. Inspecting the
> linklibs.rsp
> > file I was surprised to see that "-lgcc_eh" were nowhere to be found,
> and as
> > such the 32 bit version of this test worked fine.
> >
> > So, my question is, does anyone know under which circumstances cmake will
> > add -lgcc_eh to linklibs.rsp, and is there any way I can prevent cmake
> from
> > doing so for the 32 bit mingw-w64 compiler?
> >
> > Also, maybe I'm going about this issue the wrong way, and that my
> findings
> > mentioned above is not a good way of handling this. Or maybe this might
> be a
> > bug with the 32 bit mingw-w64 compiler?
> >
> > I should probably also mention that the 32 bit version of Mingw-w64 uses
> the
> > sjlj exception handling mechanism.
> >
> > Any help and pointers would be greatly appreciated - cause adding a step
> in
> > the developer documentation to go into the linklibs.rsp file to remove
> > -lgcc_eh is kind of a last resort.
> >
> > Thanks for any input on this matter, and please let me know if attaching
> > CMakeOutput.log or other files would be beneficial.
> >
> > Best Regards,
> > Arne Kjetil Andersen
> >
> >
> > --
> >
> > 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: 

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

[Jean-Michaël Celerier]

> 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 build properties"
> correctly.  That is of course if that is what CMake is after with
> add_library( targ INTERFACE) in the first place.
>
>
I think that there is just no mechanism for "inherited build properties".
>From the docs (
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#interface-libraries),
INTERFACE targets seems to be meant for header-only libraries.

The "inheritance" mechanism in CMake is mainly setting variables in a given
folder, but this is imho not flexible enough, and leads to problems when
you want to use your library as a subfolder of another since you don't have
an easy way to overwrite "child" variables from a parent scope unless the
child scope carefully did set(CMAKE_CXX_FLAGS "-my-flags
${CMAKE_CXX_FLAGS}") every time.


> Thanks for the heads up on yet more CMake does not do correctly.
>
> I am now climbing upon my "inherited build properties" soap box.  It's
> kinda slippery up here.
>
> On Wed, Aug 23, 2017 at 4:57 PM, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > Does that work for your needs?
>>
>> Sadly, no (but thanks!). While this is enough for the arguably common use
>> case of include directories, compile flags, etc... there are plenty of
>> things that won't work with this approach.
>>
>> e.g. none of this works for instance:
>>
>> project(foo)
>>
>> add_library(blah INTERFACE)
>> set_property(TARGET blah PROPERTY SUFFIX ".mxe")
>> set_property(TARGET blah PROPERTY CXX_STANDARD 14)
>> set_property(TARGET blah PROPERTY INSTALL_RPATH "@loader_path/whatever")
>>
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Wed, Aug 23, 2017 at 11:23 PM, Brian Davis  wrote:
>>
>>> So there is some odd replies in the cmake mailing list possibly responses 
>>> to wrong message, but this looked like a response to mine even if the 
>>> initial reply to bit is not right from Nicholas.  Anywho here goes:
>>>
>>> @Jean-Michaël Celerier
>>>
>>> -- snip --
>>> >* - Says that custom functions such as add_{project}_library shouldn't be
>>> *used and function definitions should be used as little as possible. Except
>>> this just leads to extremely verbose CMakeLists where repeated properties
>>> are defined again and again and again.
>>> -- snip --
>>>
>>> Yes add_project_library were my own and in the process of being deprecated. 
>>>  These were geared directly at two problems in cmake.
>>>
>>> 1) They were used to get CMake to support the concept of "inherited build 
>>> properties".
>>>
>>> 2) As you stated and is still a problem the verbosity of CMake.  Where IMO 
>>> much could be collaped into one call
>>>
>>>
>>> -- snip --
>>> I also never understood how to handle this.
>>> -- snip --
>>>
>>> I am afraid I don't ultimately have the answer either... I have do some 
>>> ideas on possibly best course of action.
>>>
>>>
>>> -- snip --
>>>  I have a project where I want to define, say, -fsanitize=address, -DFOO_BAR
>>> and the SUFFIX property on a specific set of 25 targets amongst ~100
>>> targets. What am I to do ?
>>>
>>> * set(CMAKE_CXX_FLAGS "-fsanitize=address") is "not modern CMake" (and also
>>> would be harder to set / unset on specific targets).
>>> * calling target_compile_options(...) 25 times ... well I mean, everyone
>>> knows it's bad to duplicate code. Especially if the change is meant to be
>>> only when a specific option() is enabled, or for debugging purposes
>>> * creating a function that would set the correct flags, etc and then call
>>> this function for each target is apparently "not modern CMake" either.
>>> * creating and linking to "dummy" INTERFACE targets with the flags and
>>> properties I want have an awful lot of limitations
>>>
>>> So what is the right course of actions here ?
>>> -- snip --
>>>
>>> I have started using add_library( targ INTERFACE ) to imperilment inherited 
>>> build properties.   Yes the naming convention and use/reuse/misuse of 
>>> add_library is horrid (library)
>>>
>>> I just posted this which may help:
>>>
>>> https://cmake.org/pipermail/cmake/2017-August/066119.html
>>>
>>> -- snip --
>>> Ideally I'd like to add "groups" to targets; e.g. "target Foo is a plugin
>>> for $software", "target Bar is an integration test" and set per-group
>>> options, flags, properties, etc. Like
>>>
>>> add_group(PluginGroup)
>>> target_compile_definitions(PluginGroup -DBLAH)
>>> set_property(GROUP PluginGroup PROPERTIES /* whatever in
>>> cmake-properties*/)
>>> set_group(myTarget PluginGroup) // applies everything to the target
>>> -- snip --
>>>
>>> I won't have all the syntax for what your trying but possibly try:
>>>
>>> add_library( 

Re: [cmake-developers] Windows symbolic links handling

[Manu]

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
GetRealPath and check for the policy prior calling it all along the code.
On the other hand, I could pass the policy status as a parameter to every
GetRealPath call. Which is the proper way?

To perform a pull request, should I previously open an issue about this or
it is enough with the discusion here in the mailing list.

Regards.



2017-08-16 11:35 GMT+02:00 Manu :

>
>
> 2017-08-15 16:43 GMT+02:00 Brad King :
>
>> On 08/14/2017 06:35 AM, Manu wrote:
>> > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP
>> ...)
>> > behaviour changed. Now it reports symbolic link timestamp instead of
>> pointed
>> > file timestamp.
>>
>> Can you track down when that happened?
>>
>>
> I happened in release 3.1.0, back 2014. The commit which changed behaviour
> was this:
>
> https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696
> ef488bdd4b
>
> In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys 
> ModifiedTime
> call. kwsys relies in system function GetFileAttributesExW which do not
> resolve symlinks, however stat does (in spite of not being documentented in
> MSDN).
>
> Removing the #ifdef WIN32 clause in ModifiedTime and using stat call
> resolves the problem, nevertheless, this change does not resolves
> get_filename_compoment symlinks issue in Windows. The problem here is again
> in kwsys, which uses system call GetFullPathNameW (which do not resolves
> symlinks) instead of GetFinalPathNameByHandleW (which does).
>
> Despite of being two different commands, I think they are very related in
> this issue and the change should be make together.
>
>
>> > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...)
>> >
>> > What troubles me is that symlink under Windows is a feature introduced
>> in
>> > Windows Vista and the change for handling them will break Windows XP
>> > compatibility. Is this acceptable?
>>
>> We still support running on XP.  If any newer Windows APIs are needed they
>> need to be looked up dynamically.  Also, behavior changes for existing
>> commands
>> may need a policy.
>>
>>
> I did not dig into cmake policies development but I am willing to submit a
> patch which includes a new policy as soon I can piece it up all together.
>
>
>> See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for
>> discussion
>> of symbolic link APIs.
>>
>> -Brad
>>
>
> Manuel.
>



-- 
La victoria puede ser creada  -  Sun Tzu.
-- 

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-developers

[CMake] CMAKE Fortran - error while coping modules

[Martin.LARCHER]

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
Martin

[ 17%] Building Fortran object source/CMakeFiles/epx.dir/m_failed_ghost_elem.f.o
cd /home/larchma/cmake/_built/source && 
/opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort -O0 -traceback -fpp 
-LIBS:static -c -debug full -debug-parameters all -I/home/larchma/cmake/include 
-c /home/larchma/cmake/source/m_failed_ghost_elem.f -o 
CMakeFiles/epx.dir/m_failed_ghost_elem.f.o
/usr/bin/cmake -E cmake_copy_f90_mod source/m_failed_ghost_elem 
source/CMakeFiles/epx.dir/m_failed_ghost_elem.mod.stamp Intel Fortran Compiler
/usr/bin/cmake -E touch 
source/CMakeFiles/epx.dir/m_failed_ghost_elem.f.o.provides.build
make[3]: Leaving directory '/home/larchma/cmake/_built'
/usr/bin/make -f source/CMakeFiles/epx.dir/build.make 
source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build
make[3]: Entering directory '/home/larchma/cmake/_built'
/usr/bin/cmake -E cmake_progress_report /home/larchma/cmake/_built/CMakeFiles
[ 17%] Building Fortran object source/CMakeFiles/epx.dir/m_material_mco_chg.f.o
cd /home/larchma/cmake/_built/source && 
/opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort -O0 -traceback -fpp 
-LIBS:static -c -debug full -debug-parameters all -I/home/larchma/cmake/include 
-c /home/larchma/cmake/source/m_material_mco_chg.f -o 
CMakeFiles/epx.dir/m_material_mco_chg.f.o
/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".
source/CMakeFiles/epx.dir/depend.make:19476: recipe for target 
'source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build' failed
make[3]: *** [source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides.build] 
Error 1
make[3]: Leaving directory '/home/larchma/cmake/_built'
source/CMakeFiles/epx.dir/build.make:7670: recipe for target 
'source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides' failed
make[2]: *** [source/CMakeFiles/epx.dir/m_material_mco_chg.f.o.provides] Error 2
make[2]: Leaving directory '/home/larchma/cmake/_built'
CMakeFiles/Makefile2:78: recipe for target 'source/CMakeFiles/epx.dir/all' 
failed
make[1]: *** [source/CMakeFiles/epx.dir/all] Error 2
make[1]: Leaving directory '/home/larchma/cmake/_built'
Makefile:120: recipe for target 'all' failed


--
Dr.-Ing. Martin Larcher
European Commission
Joint Research Centre, T.P. 480
Directorate for Space, Security and Migration
Safety and Security of Buildings
I-21027 Ispra (VA) Italy
Phone: +39-0332-789563
cmake_minimum_required (VERSION 2.6)
# set (CMAKE_VERBOSE_MAKEFILE ON)
# include(CMakeForceCompiler)
# 
CMAKE_FORCE_Fortran_COMPILER(/opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort
 "Intel Fortran Compiler")
# set(FC /opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort)
# set(CMAKE_FORTRAN_LINK_EXECUTABLE 
/opt/intel/composer_xe_2013_sp1.5.212/bin/intel64/ifort)


enable_language (CXX Fortran)
project (epx)
# Turn on the ability to create folders to organize projects (.vcproj)
# It creates "CMakePredefinedTargets" folder by default and adds CMake
# defined projects like INSTALL.vcproj and ZERO_CHECK.vcproj
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
# Set compiler flags and options. 
# Here it is setting the Visual Studio warning level to 4
# set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

# Command to output information to the console
# Useful for displaying errors, warnings, and debugging
# message ("cxx Flags: " ${CMAKE_CXX_FLAGS})
# FFLAGS depend on the compiler
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)
message ("Fortran Compiler: " ${Fortran_COMPILER_NAME})
if (Fortran_COMPILER_NAME MATCHES "gfortran.*")
  # gfortran
  set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3")
  set (CMAKE_Fortran_FLAGS_DEBUG   "-fno-f2c -O0 -g")
elseif (Fortran_COMPILER_NAME MATCHES "ifort.*")
  # ifort
  set (CMAKE_Fortran_FLAGS_RELEASE "-O3 -traceback -fpp -LIBS:static -nodebug 
-stand:f90")
  set (CMAKE_Fortran_FLAGS_DEBUG   "-Od -traceback -fpp -LIBS:static -c 
-debug:full -debug-parameters:all")
elseif (Fortran_COMPILER_NAME MATCHES "g77")
  # g77
  set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3 -m32")
  set (CMAKE_Fortran_FLAGS_DEBUG   "-fno-f2c -O0 -g -m32")
else (Fortran_COMPILER_NAME MATCHES "gfortran.*")
  message ("Fortran compiler: " ${Fortran_COMPILER_NAME})
  message ("No optimized Fortran compiler flags are known, we just try -O2...")
  set (CMAKE_Fortran_FLAGS_RELEASE "-O2")
  set (CMAKE_Fortran_FLAGS_DEBUG   "-O0 -g")
endif (Fortran_COMPILER_NAME MATCHES "gfortran.*")
if(MSVC)
  set (CMAKE_Fortran_FLAGS_RELEASE "${CMAKE_Fortran_FLAGS_RELEASE} 
-Qmkl:sequential")
  set (CMAKE_Fortran_FLAGS_DEBUG