Re: [CMake] Provide default compiler/link flags in cache before project command.

[Robert Maynard]

You should look at the CMAKE__LANG_FLAGS_INIT (
https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_FLAGS_INIT.html
) set of variables they are designed to resolve this issue.

On Fri, Jun 2, 2017 at 11:03 PM, Marco Satti  wrote:
> Hi, I am trying to let the user pick their own compiler/linker flags through
> the cache, whilst providing sane defaults.
>
>
>
> The problem is, I rely on the CMAKE_CXX_COMPILER_ID variable to set these
> defaults which is only available after the project() command is used. This
> also causes the CMAKE_CXX_FLAGS_{target} and CMAKE_EXE_LINKER_FLAGS_{target}
> to be populated in the cache by CMake, with defaults that do not work.
> Trying to set these flags after the project() command doesn’t work unless
> the FORCE flag is used… but then the user wouldn’t be able to override them.
>
>
>
> The workaround I used involved introducing a set of “USER_*” variables that
> are available in the cache (populated initially with the sane defaults),
> which then overrides the CMAKE_* variables above with the FORCE flag. It
> works, but I kind of think there should be a better way, especially since
> people who have used CMake before might try to set –DCMAKE_* using the
> command line or other wise and find it doesn’t work.
>
>
>
> Example from my CMakeLists.txt (working). I use INTERNAL instead of FORCE
> here so the user does not see this in the cmake-gui:
>
>
>
> project(myproject CXX)
>
>
>
> if(${CMAKE_CXX_COMPILER_ID} STREQUAL GNU)
>
>set(USER_CXX_FLAGS_DEBUG   "-g -std=c++14" CACHE
> STRING "CMake CXX compiler flags (Debug)."  )
>
>set(USER_EXE_LINKER_FLAGS_DEBUG   "" CACHE STRING
> "CMake CXX linker flags (Debug).")
>
> elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL MSVC)
>
>set(USER_CXX_FLAGS_DEBUG   "/MTd /Zi /Ob0 /Od /RTC1
> /MP /std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)."  )
>
>set(USER_EXE_LINKER_FLAGS_DEBUG   "/machine:x64
> /DEBUG" CACHE STRING "CMake CXX linker flags (Debug)."  )
>
> endif()
>
>
>
> … some lines below …
>
>
>
> set(CMAKE_CXX_FLAGS_DEBUG  "${USER_CXX_FLAGS_DEBUG}"
> CACHE INTERNAL "")
>
> set(CMAKE_EXE_LINKER_FLAGS_DEBUG   "${USER_EXE_LINKER_FLAGS_DEBUG}"
> CACHE INTERNAL "")
>
>
>
> Ideally, I would like to be able to do something like this (doesn’t work):
>
>
>
> project(myproject CXX)
>
>
>
> if(${CMAKE_CXX_COMPILER_ID} STREQUAL GNU)
>
>set(CMAKE_CXX_FLAGS_DEBUG   "-g -std=c++14" CACHE
> STRING "CMake CXX compiler flags (Debug)."  )
>
>set(CMAKE_EXE_LINKER_FLAGS_DEBUG   "" CACHE STRING
> "CMake CXX linker flags (Debug).")
>
> elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL MSVC)
>
>set(CMAKE_CXX_FLAGS_DEBUG   "/MTd /Zi /Ob0 /Od /RTC1
> /MP /std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)."  )
>
>set(CMAKE_EXE_LINKER_FLAGS_DEBUG   "/machine:x64
> /DEBUG" CACHE STRING "CMake CXX linker flags (Debug)."  )
>
> endif()
>
>
>
> Thanks for your time!
>
> Marco.
>
>
>
>
> --
>
> 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
-- 

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] [ANNOUNCE] CMake 3.9.0-rc2 is now ready for testing!

[Robert Maynard]

I am proud to announce the second CMake 3.9 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.9

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.9/release/3.9.html

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***

Changes made since CMake 3.8 include the following.


New Features



Languages
-

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.


Generators
--

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands


* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
-

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the 

Re: [CMake] CUDA sample using CMake 3.9

[Robert Maynard]

Hi,
Here is a collection of samples using the CUDA 3.9 support, that are
targeted around specific features.
https://gitlab.kitware.com/robertmaynard/cmake_cuda_tests/tree/master

You can also look at the CUDA and CUDAOnly tests inside CMake.
https://gitlab.kitware.com/cmake/cmake/tree/master/Tests/Cuda and
https://gitlab.kitware.com/cmake/cmake/tree/master/Tests/CudaOnly

On Wed, Jun 7, 2017 at 10:17 AM, Nagy-Egri Máté Ferenc via CMake
 wrote:
> Hi!
>
>
>
> Can anyone point to a minimalistic sample of how a CUDA application is built
> using the new CMake 3.9 support for CUDA compilation? I am mostly interested
> in promoting similar syntax of building SYCL applications that share a very
> similar compilation model, as far as ComputeCpp is concerned.
>
>
>
> Cheers,
>
> Máté
>
>
>
>
> --
>
> 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
-- 

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] Choosing Toolset v140 for Generator VS 15 2017 Win64

[Robert Maynard]

So to clarify when using the intel compiler what is the exact
generator and toolset you are specifying to CMake?

On Fri, Jun 9, 2017 at 10:05 AM, Mamales, Petros
<petros.mama...@citi.com> wrote:
> Hi Robert,
> Thank you for your response.
> However, this mail was superseded by another one - actually this being my 
> first email to the mailing list I received notification that it would not get 
> published as I was not yet a member.
> As it turns out, it does find the toolset (I am very curious as to how, 
> actually, as I spent considerable time to second-guess it). However the 
> compiler fails to generate code due to missing libraries when it tries to 
> perform its tests.
> Any idea on how I can provide with extra include/lib directories through 
> CMake to the "tester"(MSBuild?)? (all these happen upon declaration of a 
> project as a c++ one).
> Here is the ouput I get in the error log (copying from my follow-up email):
> Compiling the CXX compiler identification source file 
> "CMakeCXXCompilerId.cpp" failed.
> Compiler:
> Build flags:
> Id flags:
>
> The output was:
> 1
> Microsoft (R) Build Engine version 14.0.25420.1
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Build started 6/8/2017 12:09:12 PM.
> Project 
> "C:\_petros\_dev\math_dev\_build_trees\x64\vc14-intel-17_0_0\CMakeFiles\3.9.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj"
>  on node 1 (default targets).
> PrepareForBuild:
>   Creating directory "Debug\".
>   Creating directory "Debug\CompilerIdCXX.tlog\".
> InitializeBuildStatus:
>   Creating "Debug\CompilerIdCXX.tlog\unsuccessfulbuild" because 
> "AlwaysCreate" was specified.
> MessageBuildingWithCompiler:
>   Building with Intel(R) C++ Compiler 17.0
> ClCompile:
>   * ClCompile (x64 - Intel C++)
>   C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\bin\intel64\icl.exe
>  /c /Qm64 /nologo /W0 /Od /D __INTEL_COMPILER=1700 /D _MBCS /EHsc /RTC1 /MDd 
> /GS /Zc:wchar_t /Zc:forScope /Fo"Debug\\" /Fd"Debug\vc140.pdb" /TP 
> CMakeCXXCompilerId.cpp
>   CMakeCXXCompilerId.cpp
> Link:
>   C:\Program Files 
> (x86)\IntelSWTools\compilers_and_libraries_2017.0.109\windows\bin\intel64\xilink.exe
>  -qm64 /OUT:".\CompilerIdCXX.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib 
> user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib 
> ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST 
> /manifest:embed /MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
> /PDB:".\CompilerIdCXX.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT 
> /IMPLIB:".\CompilerIdCXX.lib" /MACHINE:X64 Debug\CMakeCXXCompilerId.obj
> LINK : : error LNK1104: cannot open file 'libmmdd.lib' 
> [C:\_petros\_dev\math_dev\_build_trees\x64\vc14-intel-17_0_0\CMakeFiles\3.9.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj]
> Done Building Project 
> "C:\_petros\_dev\math_dev\_build_trees\x64\vc14-intel-17_0_0\CMakeFiles\3.9.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj"
>  (default targets) -- FAILED.
>
> Build FAILED.
>
> Thank you for trying to help,
> Petros
>
> PS: the follow-up email has title:
> CMake problem with intel parallel studio 2017
>
>
>
>
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Maynard
> Sent: Friday, June 09, 2017 8:57 AM
> To: Valmiki Rampersad
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Choosing Toolset v140 for Generator VS 15 2017 Win64
>
> Hi,
>
> Can you provide the contents of the build directory file 
> CMakeFiles/CMakeError.log . That might help us figure out why the toolset is 
> not found
>
> On Tue, May 30, 2017 at 10:44 PM, Valmiki Rampersad 
> <valmiki_ramper...@hotmail.com> wrote:
>> I have Visual Studio 2017 Community, with toolsets v141 and v140, installed.
>>
>>
>> If I run 'cmake -G "Visual Studio 15 2017 Win64" -T v141', it
>> correctly configures and generates the project.
>>
>>
>> However, if I run 'cmake -G "Visual Studio 15 2017 Win64" -T v140' it
>> returns with the errors "No CMAKE_C_COMPILER could be found" and "No
>> CMAKE_CXX_COMPILER could be found".
>>
>>
>> I am using CMake 3.8.1. Any help in solving this would be greatly
>> appreciated!
>>
>>
>> --
>>
>> Powered by
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com=
>> DwICAg=j-EkbjBYwkAB4f8ZbVn1Fw=6_wuzZXSt4ORpgK3tgk-CcUFf9XSS7xAF6v6
>> 9MPzaXs=3P1PLWvluZuxCLJLeuyiWC2Faruz7Sk2b0TYJMRijCo=3UW1rsfR6g_UG5
>> 3Giev2l

Re: [CMake] Choosing Toolset v140 for Generator VS 15 2017 Win64

[Robert Maynard]

Hi,

Can you provide the contents of the build directory file
CMakeFiles/CMakeError.log . That might help us figure out why the
toolset is not found

On Tue, May 30, 2017 at 10:44 PM, Valmiki Rampersad
 wrote:
> I have Visual Studio 2017 Community, with toolsets v141 and v140, installed.
>
>
> If I run 'cmake -G "Visual Studio 15 2017 Win64" -T v141', it correctly
> configures and generates the project.
>
>
> However, if I run 'cmake -G "Visual Studio 15 2017 Win64" -T v140' it
> returns with the errors "No CMAKE_C_COMPILER could be found" and "No
> CMAKE_CXX_COMPILER could be found".
>
>
> I am using CMake 3.8.1. Any help in solving this would be greatly
> appreciated!
>
>
> --
>
> 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
-- 

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] Adding external static library into a target static library

[Robert Maynard]

The example you provided shows how you can combine raw object files
into a single library. As far as I am aware CMake doesn't offer a nice
cross platform API  for extracting the object files from a static
library and adding them to a new static library.



On Thu, Jun 15, 2017 at 10:19 PM, Pawel Veselov  wrote:
> Hello.
>
> I looked at this : https://cmake.org/Wiki/CMake/Tutorials/Object_Library,
> and it suggests that I can use target_link_library() to combine static
> libraries together. But I'm utterly failing at it.
>
> Simple:
> add_library(mylib STATIC ${lib_source})
> target_link_libraries(mylib /path/to/libcool.a)
>
> Doesn't work (libcool.a is not appended into mylib.a). If I want to link
> against mylib (inside same cmake), then the libcool.a is added, however,
> into the linkage of the executable that uses mylib.
>
>
> I've tried making it more complicated by separating objects into an object
> library, and then combining that object library and the external .a together
> but it also doesn't do much:
>
> add_library(mylib-obj OBJECT ${lib_source})
> add_library(mylib STATIC $ /path/to/libcool.a)
>
> or
>
> add_library(mylib-obj OBJECT ${lib_source})
> add_library(mylib STATIC $)
> target_link_libraries(mylib /path/to/libcool.a)
>
> In all cases, cmake schedules ar on the object files, and ranlib on the
> result.
>
> Also, it seems it's not possible to create an empty library and add
> other libraries as dependencies, which, in case of static libraries,
> would make sense...
>
> So, is is possible to, using cmake (and not do manual ar manipulations),
> to create a static library containing objects from another static library,
> external to the project?
>
> Thank you!
>
> --
>
> 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
-- 

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] Missing _EXPORTS definition in CUDA host compilation

[Robert Maynard]

Hi James,

I have created a bug report for this issue, which you can track at:
https://gitlab.kitware.com/cmake/cmake/issues/16993

On Fri, Jun 16, 2017 at 12:14 PM, Hancox, James  wrote:
> Hi,
>
>
>
> I’m trying out the new CUDA support for Visual Studio generators in Cmake
> 3.9.0-rc3 (generator Visual Studio 12 2013 Win64), and I think I’ve found a
> bug.
>
>
>
> Our code defines some DLL-export functions in host code in a .cu file, but
> it seems that the usual _EXPORTS pre-processor definition is missing
> for host code compilation invoked from NVCC. We have the usual DLL
> boilerplate defined in a header like so:
>
>
>
> #ifdef example_target_EXPORTS
>
> #define EXAMPLE_TARGET_API _declspec(dllexport)
>
> #else
>
> #define EXAMPLE_TARGET_API _declspec(dllimport)
>
> #endif
>
>
>
> However in my .cu file, EXAMPLE_TARGET_API is being expanded to
> _declspec(dllimport), not _declspec(dllexport) . It would appear that
> example_target_EXPORTS is not being declared.
>
>
>
> Is this intended behaviour, or a bug? If intended behaviour, what is the
> mechanism I should be using instead?
>
>
>
> Many thanks,
>
> James Hancox
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.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
-- 

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] CMake 3.9.0-rc3 is now ready for testing!

[Robert Maynard]

projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


Other Changes
=

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".


Changes made since CMake 3.9.0-rc2:

Brad King (6):
  C++ feature checks: Improve exclusion of "0 Warning(s)"
  FindDoxygen: Create imported targets at most once in a given scope
  Android: Detect API version of standalone toolchain with unified headers
  Android: Do not pass sysroot include for standalone toolchain
  Android: Add support for unified headers
  CMake 3.9.0-rc3

Robert Maynard (1):
  CUDA: When linking device code suppress CUDA 8.0+ deprecation warnings

Rolf Eike Beer (2):
  FindPkgConfig: fix confusing indentation
  FindPkgConfig: mention that variables will be ;-lists
-- 

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] Circular dependencies with Ninja, not with Unix Makefiles

[Robert Maynard]

Hi,

This is caused by doing an in source build and thereby causing the issue.
The custom command is outputting a file called 'foo', which is also the
chosen name of a target in the ninja file. All of this results in ninja
conflating the two and causing a circular dependency.

Your options are to not to in source builds, or to choose a different name
for your custom target.

On Thu, May 4, 2017 at 3:55 AM, Ignacio Fernández Galván via CMake <
cmake@cmake.org> wrote:

> Hello,
>
> I have a project where circular dependencies are generated when I use the
> Ninja generator, but not the default Unix Makefiles. I could create a
> minimal test like this:
>
> $ cat CMakeLists.txt
> add_subdirectory (ext ${PROJECT_BINARY_DIR}/ext)
>
> $ cat ext/CMakeLists.txt
> set (OUT ${CMAKE_CURRENT_LIST_DIR})
>
> add_custom_command (OUTPUT ${OUT}/foo
> COMMAND touch ${OUT}/foo
> )
>
> add_custom_target (foo ALL
> DEPENDS ${OUT}/foo
> )
>
> add_custom_command (TARGET foo
> POST_BUILD
> COMMAND cp ${OUT}/foo ${CMAKE_BINARY_DIR}/foo
> )
>
> $ touch ext/bar
>
> $ cmake -G Ninja .
> [...]
>
> $ ninja
> ninja: warning: multiple rules generate ext/foo. builds involving this
> target will not be correct; continuing anyway [-w dupbuild=warn]
> ninja: error: dependency cycle: ext/foo -> ext/CMakeFiles/foo.util ->
> ext/CMakeFiles/foo -> ext/foo
>
> I used a freshly compiled CMake 3.8 and the latest binary ninja from
> https://github.com/Kitware/ninja/releases.
>
> Ignacio
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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] avoiding finding system libraries (motivation is superbuilds)

[Robert Maynard]

Have you tried using CMAKE_PREFIX_PATH instead of CMAKE_INSTALL_PREFIX?

On Thu, May 4, 2017 at 5:13 PM, Kris Thielemans  wrote:

> Hi
>
>
>
> Short question: if we have a library/include files installed both in the
> usual system locations and outside, how do we force CMake to find the
> latter? (without modifying the CMake files of the project).
>
>
>
> Motivation:
>
> We’re trying to make a SuperBuild that builds/downloads a specific version
> of various packages (such as Boost and GTest). Our motivation is to have
> complete control of the version. We don’t want to install this in standard
> locations to avoid clashes, root permissions etc.  So let’s say we install
> our versions in ~/our_stuff/lib, ~/our_stuff/include etc
>
>
>
> It seems very hard (and sometimes impossible) however to let future
> find_packages find our own versions as opposed to the system ones. From
> https://cmake.org/cmake/help/latest/command/find_library.html I thought
> that doing something like this would work
>
>
>
> cmake ../ -DCMAKE_INSTALL_PREFIX=~/our_stuff
>
>
>
> but the system version of boost etc are still found first (it does work if
> there is no system version of the library). In the case of Boost, even
>
>
>
> cmake ../ -DCMAKE_INSTALL_PREFIX=~/our_stuff -DBOOST_ROOT=~/our_stuff
>
>
>
> doesn’t help (tested on Linux). I have to set BOOST_INCLUDEDIR for
> instance. As every Find*.cmake has its own conventions of specifying
> cmake/environment variables, and some don’t at all, this just gets
> unfeasible.
>
>
>
> I know about NO_DEFAULT_PATH, NO_CMAKE_SYSTEM_PATH etc options for
> find_package, but this would need modification of CMake files in the
> dependent packages which is quite undesirable for us.
>
>
>
> Any suggestions?
>
>
>
> Thanks
>
> Kris
>
>
>
> --
>
> 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
>
-- 

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] [ANNOUNCE] CMake 3.8.1 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.8.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.8.1 since 3.8.0:

Alex Turbov (2):
  FindOpenSSL: Add more library name alternatives
  FindBoost: Restore tolerance of backslashes in paths

Brad King (4):
  Tests: Fix FindModulesExecuteAll when KDE4 is installed
  Tests: Simplify CMakeOnly.AllFindModules policy settings
  FindBoost: Fix library directory for VS 2017
  CMake 3.8.1

Domen Vrankar (1):
  CPack/RPM doc: CPACK_RPM_BUILDREQUIRES docs

Mateusz Janek (1):
  source_group: Fix TREE with root that is not current source dir

Raffi Enficiaud (1):
  FindMatlab: Add support for Matlab 2017a

Richard Walters (1):
  VS: Fix project reference inspection in VS IDE

Roger Leigh (3):
  FindBoost: Allow testing for multiple compiler suffixes
  FindBoost: Support prebuilt Windows binaries from SourceForge
  VS2017: Verify Windows 8.1 SDK before using it
-- 

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] CPack not detecting pkgbuild or product build

[Robert Maynard]

Hi,

By default the NSIS generator is enabled.

On Wed, May 3, 2017 at 6:39 PM, Ayla Khan <a...@sci.utah.edu> wrote:

> That worked - thank you! Do I need to add NSIS manually for Windows
> installers as well? It looks like CMake finds NSIS without any difficulty
> but I’d rather be sure.
>
> Thanks,
>
> Ayla
>
> On May 3, 2017, at 2:56 PM, Robert Maynard <robert.mayn...@kitware.com>
> wrote:
>
> You will need to append the productbuild type to you CPACK_GENERATOR so
> it would look like SET(CPACK_GENERATOR "productbuild;STGZ;TGZ")
>
> On Wed, May 3, 2017 at 4:14 PM, Ayla Khan <a...@sci.utah.edu> wrote:
>
>> Thank you Robert. The CPACK_GENERATOR variable is currently set to
>> “STGZ;TGZ”. When I installed Xcode, I made sure using xcode-select that the
>> usual command line tools were installed. I can find productbuild in my
>> PATH, but CPACK_BINARY_PRODUCTBUILD is off in CPackConfig.cmake. Do I need
>> to explicitly set CPACK_BINARY_PRODUCTBUILD in my CMakeLists.txt, or do I
>> append a type for packages to CPACK_GENERATOR? I assumed CPACK_GENERATOR
>> was generated automatically.
>>
>> Also, I’ve been working with Xcode 8 on OS X 10.11.6, and CPack is
>> ignoring productbuild completely even if I set it using the generator flag.
>> Command line tools were also set up using xcode-select.
>>
>> Thanks,
>>
>> Ayla
>>
>> > On May 3, 2017, at 1:12 PM, Robert Maynard <robert.mayn...@kitware.com>
>> wrote:
>> >
>> > Hi Ayla,
>> >
>> > The packages that are built when executing "make package" is determined
>> by the variable "CPACK_GENERATOR" inside your CPackConfig.cmake ( generally
>> located in the root of your build directory as it is configured ).
>> >
>> >
>> > On Fri, Apr 7, 2017 at 3:44 PM, Ayla Khan <a...@sci.utah.edu> wrote:
>> > I’m trying to build a Mac OS X installer package on 10.10.5 using Xcode
>> 7.2 tools with the CPack that ships with CMake 3.7.2. I can generate a
>> package from the CMake build directory if I call cpack directly on the
>> command line with -G productbuild, but not through the CMake build using
>> make package. Is there a CPack setting I need or some other build
>> configuration information? Is the Xcode version too old?
>> >
>> > Thanks,
>> >
>> > Ayla
>> > --
>> >
>> > 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
>> >
>>
>>
>
>
-- 

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] [ANNOUNCE] CMake 3.9.0-rc1 now ready for testing

[Robert Maynard]

I am proud to announce the first CMake 3.9 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.9

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.9/release/3.9.html

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***

Changes made since CMake 3.8 include the following.


New Features



Languages
-

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.


Generators
--

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands


* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
-

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the 

Re: [CMake] Understanding constraint graph cycles

[Robert Maynard]

Yes,

You most likely want to look at BUILD_RPATH or INSTALL_RPATH depending
on if these libraries are located in your build directory or install
directory.

On Mon, Sep 4, 2017 at 4:39 PM, James Turner <james.tur...@kdab.com> wrote:
>
> On 4 Sep 2017, at 18:37, Robert Maynard <robert.mayn...@kitware.com> wrote:
>
> Yes you are correct the issue is related to rpath. When CMake constructs the
> rpath for the library linking it will have two paths (
> /home/jenkins/workspace/FlightGear/dist/lib64,
> /home/jenkins/workspace/SimGear/dist/lib64) each that contain a copy of
> libosgText.so.130. CMake is warning that which version of libosgText is
> undefined.
>
>
> Can I control whether CMake includes the rpath flags for a static library
> like SimGear? Normally the default behaviour is correct but for this
> particular config it would be easier to disable the rpath for OSG inside
> SimGear, than adjust the build setup to use a common dist dir, I think.
>
> 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] [ANNOUNCE] CMake 3.10.0-rc2 is now ready for testing

[Robert Maynard]

LABELS_FOR_SUBPROJECTS" CTest module variable and CTest
  script variable were added to specify a list of labels that should
  be treated as subprojects by CDash. To use this value in both the
  CTest module and the ctest command line Dashboard Client mode (e.g.
  "ctest -S") set it in the "CTestConfig.cmake" config file.


CPack
-

* CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)",
  configured by the "CPackFreeBSD" module.

* The CPack "DEB" generator, configured by the "CPackDeb" module,
  was enabled on Windows.  While not fully featured (due to the lack
  of external UNIX tools) this will allow building basic cross-
  platform Debian packages.

* The "CPackDeb" module learned to set package release version in
  "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE"
  variable.

* The "CPackDeb" module learned more strict package version checking
  that complies with Debian rules.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "REPLACES" and "CHECKABLE" options.

* The "CPackIFW" module gained new
  "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target
  binary format.

* The "CPackIFW" module gained new
  "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional
  repositories dirs that will be used to resolve and repack dependent
  components. This feature is only available when using QtIFW 3.1 or
  later.

* Modules "CPackRPM" and "CPackDeb" learned to set package epoch
  version. See "CPACK_RPM_PACKAGE_EPOCH" and
  "CPACK_DEBIAN_PACKAGE_EPOCH" variables.


Other
-

* The "cmake(1)" "-E" mode gained support for "sha1sum",
  "sha224sum", "sha256sum", "sha384sum", and "sha512sum".

* The graphviz output now distinguishes among the different
  dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents
  them in the output graph as solid, dashed and dotted edges.


Deprecated and Removed Features
===

* Support for building CMake itself with C++98 compilers was
  dropped. CMake is now implemented using C++11.

* Support for building CMake on HP-UX has been dropped pending
  better support for C++11 and a port of libuv.  See CMake Issue
  17137. Use CMake 3.9 or lower instead for HP-UX support.


Other Changes
=

* On FreeBSD the C++ compiler named "c++" is now the preferred
  default.

* The "file(GENERATE)" command now interprets relative paths given
  to its "OUTPUT" and "INPUT" arguments with respect to the caller's
  current binary and source directories, respectively. See policy
  "CMP0070".

* The "get_filename_component()" "PROGRAM" mode semantics have been
  revised to not tolerate unquoted spaces in the path to the program
  while also accepting arguments.  While technically incompatible with
  the old behavior, it is expected that behavior under typical use
  cases with properly-quoted command-lines has not changed.


Changes made since CMake 3.9.0-rc1:

André Apitzsch (1):
  FindProtobuf: fix documentation typo

Brad King (10):
  Help: Revise 3.10 release notes
  FindJava: Revise version parsing to support Java 9
  curl: Update script to get curl 7.56.0
  curl: Update build within CMake to account for 7.56 changes
  Help: Minor text clarifications in cmake-language(7) manual
  Clang: Diagnose unsupported GNU-like clang targeting MSVC ABI
  ExternalProject: Avoid if() auto-dereferene in quoted arguments
  FindXMLRPC: Drop unnecessary exec_program code paths
  FindXMLRPC: Tolerate no include directories
  CMake 3.10.0-rc2

Christian Pfeiffer (1):
  FindOpenMP: Fix link flags being used for compile

Craig Scott (2):
  Help: Fix Example appearing in target property list of contents
  Help: Fix wrong property reference for an app bundle's Info.plist

Curl Upstream (1):
  curl 2017-10-04 (3ea76790)

Domen Vrankar (2):
  CPack/Deb: CPACK_DEBIAN_PACKAGE_VERSION regex testing exception
  CPack/Deb: fix for regex passing even if invalid characters are present

Gregor Jasny (2):
  Revert "Xcode: Adjust tests to drop of 32bit iOS architectures"
  Xcode 9: Lower iOS deployment version to get armv7 builds

Matthias Maennich (4):
  cmcmd: let operator<< for NumberFormatter reset the stream's format flags
  cmGeneratorTarget: remove dead code
  cmProcessTools: fix minor issue introduced by 595feb3
  cmInstallCommandArguments: do not access static members through `this`

Robert Maynard (1):
  FindCUDA: Update for CUDA 9 breakup of nppi into multiple libraries

Sebastian Holtermann (3):
  Autogen: Allow setting SKIP_AUTOUIC/GEN on .ui files not in the sources
  Autogen: Docs: Add examples for AUTORCC_OPTIONS and AUTOUIC_OPTIONS
  Autogen: Docs: Extend SKIP_AUTOUIC documentation

Thomas Stenersen (1):
  IPO: Fix support for spaces in path to archive tools
-- 

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] Future direction for FindCUDA

[Robert Maynard]

> Can I link to CUDA libraries with GCC while not using FindCUDA

Yes you can if you have enabled the CUDA language. You will need to
use find_package and can use the CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES
as the location(s) to search.

> Instead of modifying what FindCUDA does, which would break backwards 
> compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or 
> something like that.

That is something I have wanted to do, but haven't had the time to
formalize and finish. You can find my initial implementation at
https://gitlab.kitware.com/robertmaynard/find_cuda_wrappers

On Wed, Aug 30, 2017 at 5:06 AM, Mueller-Roemer, Johannes Sebastian
 wrote:
> Hi,
>
> we have encountered this issue as well, in our case when using thrust on the 
> host side. We currently solve this by still using FindCUDA, even when using 
> CMake 3.8/3.9, but only using the CUDA_*_LIBRARY and CUDA_TOOLKIT_INCLUDE 
> variables and nothing else.
>
> Instead of modifying what FindCUDA does, which would break backwards 
> compatibility, FindCUDA could be split into FindCUDA and FindCUDALibraries or 
> something like that.
>
> Regards
> Johannes
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Siyuan Liu
> Sent: Wednesday, August 30, 2017 07:05
> To: cmake@cmake.org
> Subject: [CMake] Future direction for FindCUDA
>
> Dear all,
>
> I've noticed the change to CUDA as a language in CMake 3.8. I've migrated to 
> this new syntax, but this change leads to some difficulties for me with 
> CMake. I think we should treat CUDA as not just a language but rather a 
> language with some libraries.
>
> Now that the FindCUDA module is deprecated, I cannot compile a file with GCC 
> while linking to a CUDA library (since the CUDA_xxx_LIBRARY variables are 
> gone). The reason for not using NVCC is to save compilation time. Personally, 
> I think FindCUDA should become a module for purely finding CUDA libraries for 
> linking without anything related to the NVCC compiler (e.g. the 
> cuda_add_executable macro).
>
> My questions in short:
> 1. Can I link to CUDA libraries with GCC while not using FindCUDA?
> 2. What's your opinion on my suggestion about FindCUDA?
>
> Regards,
> Siyuan
> --
>
> 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
> --
>
> 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
-- 

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 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Robert Maynard]

As far as gencode goes, your line has errors. With CUDA 8 it should look
like:

-gencode arch=compute_20,code=\"sm_20,compute_20\"



On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> I’m having two issues with debug symbols for CUDA libraries on a project:
>
>
>
> 1.   The PDBs are not placed where the linker later expects to find
> them (haven’t been able to replicate this in a minimal project yet)
>
> 2.   Trying to circumnavigate this issue by using “/Z7” instead of
> “/Zi” does not work, Zi is always used (replicable in any project with CUDA)
>
> Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by
> -Z7 or /Z7. Build and see several warnings like “cl : Command line warning
> D9025: overriding '/Z7' with '/Zi'” in the output window.
> And do the flags in the –Xcompiler make sense at all in VS? The CUDA build
> tools seem to determine these automatically anyways… for example I get the
> following call in the above scenario:
>
> "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe"
> -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env
> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g
> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
> A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu"
>
> 3.   Also, -gencode flags do not behave as expected when given in the
> form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the
> VS build system to error out:
>
> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item
> '..\..\a\a.cu' Code Generation value is not in the expected format
> '[Arch],[Code]'.
>
> The code generation value in this example is set to
> compute_20,sm_20,compute_20 by CMake.
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606 <+49%206151%20155606>  |  Fax +49 6151 155-139
> <+49%206151%20155139>
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
> --
>
> 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
>
-- 

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 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Robert Maynard]

Yes I was responding to comment 3.

I am curious, does the longer form signature "-gencode
arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20" work
correctly? CMake has to parse the gencode flags and move them to special
msbuild entries, and I wonder if there is a bug when parsing multiple code
options.

On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> If the comment is wrt 3., the result is the same no matter if I use a
> space or an equals sign, if I double escape the quotes (e.g., use the value
> as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS
> becomes compute_20,"sm_20,compute_20" instead of
> compute_20,sm_20,compute_20, which is equally illegal and will cause the
> same error message, also double escaping should not be necessary for a
> subset of flags (Xcompiler works fine without it, even if the default
> values are pointless).
>
> If the comment is wrt 2., this is the line automatically generated by
> CMake/VS when not passing in any gencode flags explicitly.
>
>
>
> Or am I misunderstanding what you mean?
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606 <+49%206151%20155606>  |  Fax +49 6151 155-139
> <+49%206151%20155139>
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
> *From:* Robert Maynard [mailto:robert.mayn...@kitware.com]
> *Sent:* Wednesday, September 6, 2017 15:38
> *To:* Mueller-Roemer, Johannes Sebastian  roe...@igd.fraunhofer.de>
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
> issues
>
>
>
> As far as gencode goes, your line has errors. With CUDA 8 it should look
> like:
>
> -gencode arch=compute_20,code=\"sm_20,compute_20\"
>
>
>
>
>
> On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian <
> johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:
>
> I’m having two issues with debug symbols for CUDA libraries on a project:
>
>
>
> 1.   The PDBs are not placed where the linker later expects to find
> them (haven’t been able to replicate this in a minimal project yet)
>
> 2.   Trying to circumnavigate this issue by using “/Z7” instead of
> “/Zi” does not work, Zi is always used (replicable in any project with CUDA)
>
> Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by
> -Z7 or /Z7. Build and see several warnings like “cl : Command line warning
> D9025: overriding '/Z7' with '/Zi'” in the output window.
> And do the flags in the –Xcompiler make sense at all in VS? The CUDA build
> tools seem to determine these automatically anyways… for example I get the
> following call in the above scenario:
>
> "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe"
> -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env
> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g
> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
> A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu"
>
> 3.   Also, -gencode flags do not behave as expected when given in the
> form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the
> VS build system to error out:
>
> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item
> '..\..\a\a.cu' Code Generation value is not in the expected format
> '[Arch],[Code]'.
>
> The code generation value in this example is set to
> compute_20,sm_20,compute_20 by CMake.
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606 <+49%206151%20155606>  |  Fax +49 6151 155-139
> <+49%206151%20155139>
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
>
> --
>
> 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:
>
> CMak

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Robert Maynard]

Okay I have opened an issue on CMake for handling multiple gencode with
multiple code targets.

On Wed, Sep 6, 2017 at 3:19 PM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> Yes
>
> ____
> From: Robert Maynard [robert.mayn...@kitware.com]
> Sent: Wednesday, September 06, 2017 6:58 PM
> To: Mueller-Roemer, Johannes Sebastian
> Cc: cmake@cmake.org
> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
> issues
>
> So it works when they are separate gen-code options, but fails when they
> are combined. Is that correct?
>
>
> On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian <
> johannes.sebastian.mueller-roe...@igd.fraunhofer.de johannes.sebastian.mueller-roe...@igd.fraunhofer.de>> wrote:
> The long form fills the Code Generation field with
> compute_20,sm_20;compute_20,compute_20 (the default without gencode
> parameters is compute_20,sm_20) and results in the following command line:
>
> D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU
> Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
> -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env
> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g
>  -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
> A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu<
> http://a.cu>"
>
> Which is somewhat redundant
>
> MSVC turns compute_20,sm_20 into 
> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
> and compute_20,compute_20 into -gencode=arch=compute_20,code=
> \"compute_20,compute_20\"
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151 155-139
> <tel:+49%206151%20155139>
> johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.
> mueller-roe...@igd.fraunhofer.de> | www.igd.fraunhofer.de<http://
> www.igd.fraunhofer.de>
>
> From: Robert Maynard [mailto:robert.mayn...@kitware.com<mailto:robert.
> mayn...@kitware.com>]
> Sent: Wednesday, September 6, 2017 16:44
>
> To: Mueller-Roemer, Johannes Sebastian  roe...@igd.fraunhofer.de<mailto:Johannes.Sebastian.
> mueller-roe...@igd.fraunhofer.de>>
> Cc: cmake@cmake.org<mailto:cmake@cmake.org>
> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
> issues
>
> Yes I was responding to comment 3.
>
> I am curious, does the longer form signature "-gencode
> arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20"
> work correctly? CMake has to parse the gencode flags and move them to
> special msbuild entries, and I wonder if there is a bug when parsing
> multiple code options.
>
> On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian <
> johannes.sebastian.mueller-roe...@igd.fraunhofer.de johannes.sebastian.mueller-roe...@igd.fraunhofer.de>> wrote:
> If the comment is wrt 3., the result is the same no matter if I use a
> space or an equals sign, if I double escape the quotes (e.g., use the value
> as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS
> becomes compute_20,"sm_20,compute_20" instead of
> compute_20,sm_20,compute_20, which is equally illegal and will cause the
> same error message, also double escaping should not be necessary for a
> subset of flags (Xcompiler works fine without it, even if the default
> values are pointless).
> If the comment is wrt 2., this is the line automatically generated by
> CMake/VS when not passing in any gencode flags explicitly.
>
> Or am I misunderstanding what you mean?
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151 155-139
> <tel:+49%206151%20155139>
> johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.
> mueller-roe...@igd.fraunhofer.de> | www.igd.fraunhofer.de<http://
> www.igd.fraunhofer.de>
>
> From: Robert Maynard [mailto:robert.mayn...@kitware.com<mailto:robert.
> mayn...@kitware.com>]
> Sent: Wednesday, September 6, 20

[CMake] [ANNOUNCE] CMake 3.9.2 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.9.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.9.2 since 3.9.1:

Brad King (13):
  InstallRequiredSystemLibraries: Factor redist name into variable
  InstallRequiredSystemLibraries: Find VS 2017 Update 3 redist directory
  macOS: Revert default Hi-DPI support in applications
  Ninja: Fix support for MSVC with non-English output
  Xcode: Revert addition of "outputPaths" to custom command build phase
  cmCPackDragNDropGenerator: Add missing include
  cmake: Fix --find-package mode with imported targets
  Genex: Fix TARGET_PROPERTY value of SOURCES
  Android: Update for NDK r16
  FindBoost: Revert "Simplify search in lists."
  InstallRequiredSystemLibraries: Add support for future VS 2017 toolchains
  Tests: Fix RunCMake.GeneratorExpression to run in CMake 3.9
  CMake 3.9.2

Christian Pfeiffer (1):
  FindOpenMP: Restore OpenMP_FOUND result variable

Maikel van den Hurk (1):
  CUDA: Pass host compiler to nvcc while device linking

Michael Stürmer (2):
  VS: Do not reference output assemblies if not possible for CSharp target
  VS: Initialize CSharp flags consistently

Sebastian Holtermann (3):
  Autogen: Restore AUTOUIC lookup paths from 3.8.2
  Autogen: Update AUTOUIC documentation for search paths
  Autogen: Extend AUTOUIC search paths test

Sylvain Joubert (1):
  Clang: Find version-suffixed LLVM/Clang binutils

Tibor Szabo (1):
  FindCygwin: Fix regression when CYGWIN_INSTALL_PATH is already set
-- 

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 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Robert Maynard]

So it works when they are separate gen-code options, but fails when they
are combined. Is that correct?


On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> The long form fills the Code Generation field with
> compute_20,sm_20;compute_20,compute_20 (the default without gencode
> parameters is compute_20,sm_20) and results in the following command line:
>
>
>
> D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU
> Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" 
> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
> -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env
> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g
> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
> A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu"
>
>
>
> Which is somewhat redundant
>
>
>
> MSVC turns compute_20,sm_20 into 
> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
> and compute_20,compute_20 into -gencode=arch=compute_20,code=
> \"compute_20,compute_20\"
>
>
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606 <+49%206151%20155606>  |  Fax +49 6151 155-139
> <+49%206151%20155139>
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
> *From:* Robert Maynard [mailto:robert.mayn...@kitware.com]
> *Sent:* Wednesday, September 6, 2017 16:44
>
> *To:* Mueller-Roemer, Johannes Sebastian  roe...@igd.fraunhofer.de>
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
> issues
>
>
>
> Yes I was responding to comment 3.
>
>
>
> I am curious, does the longer form signature "-gencode
> arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20"
> work correctly? CMake has to parse the gencode flags and move them to
> special msbuild entries, and I wonder if there is a bug when parsing
> multiple code options.
>
>
>
> On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian <
> johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:
>
> If the comment is wrt 3., the result is the same no matter if I use a
> space or an equals sign, if I double escape the quotes (e.g., use the value
> as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS
> becomes compute_20,"sm_20,compute_20" instead of
> compute_20,sm_20,compute_20, which is equally illegal and will cause the
> same error message, also double escaping should not be necessary for a
> subset of flags (Xcompiler works fine without it, even if the default
> values are pointless).
>
> If the comment is wrt 2., this is the line automatically generated by
> CMake/VS when not passing in any gencode flags explicitly.
>
>
>
> Or am I misunderstanding what you mean?
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606 <+49%206151%20155606>  |  Fax +49 6151 155-139
> <+49%206151%20155139>
>
> johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
>
>
>
> *From:* Robert Maynard [mailto:robert.mayn...@kitware.com]
> *Sent:* Wednesday, September 6, 2017 15:38
> *To:* Mueller-Roemer, Johannes Sebastian  roe...@igd.fraunhofer.de>
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
> issues
>
>
>
> As far as gencode goes, your line has errors. With CUDA 8 it should look
> like:
>
> -gencode arch=compute_20,code=\"sm_20,compute_20\"
>
>
>
>
>
> On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian <
> johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:
>
> I’m having two issues with debug symbols for CUDA libraries on a project:
>
>
>
> 1.   The PDBs are not placed where the linker later expects to find
> them (haven’t been able to replicate this in a minimal project yet)
>
> 2.   Trying to circumnavigate this issue by using “/Z7” instead of
> “/Zi” does not work, Zi is always used (replicable in any project with CUDA)
>

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

[Robert Maynard]

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.

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

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?

[Robert Maynard]

Usage of link_directories is discouraged, and was part of the reason
why a target based option was not added. As the documentation for
link_directories states "Note that this command is rarely necessary.
Library locations returned by find_package() and find_library() are
absolute paths. Pass these absolute library file paths directly to the
target_link_libraries() command. CMake will ensure the linker finds
them."

On Mon, Aug 21, 2017 at 8:17 PM, Brian Davis  wrote:
> Why does:
>
> Interface Libraries
> https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3
>
> allow include directories via
>
> target_include_directories(INTERFACE)
>
> but not link_directories
>
> https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_directories
>
> which if we look at property scope:
>
> https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html
>
> Why is include_directories at target resolution while link_directories is at
> directory resolution.
>
> link_directories is a property on a directory which if I recalled correctly
> I complained about many many moons ago (circa 2009) when I first realized
> this.  I did not understand this logic then and don't understand this logic
> now.  Someone what to give me the recipe for the CMake cool-aid so I can mix
> that up, drink it down, and re-read the doc and finally come to terms with
> this.  Or could the powers that be redesign CMake to make sense.  At the
> time I wrapped this nonsense in a macro and pretended it did not happen ...
> now I am rewriting my project for "new" CMake and still don't get this.
>
>
>
>
> --
>
> 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
-- 

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] Understanding constraint graph cycles

[Robert Maynard]

Hi,

Yes you are correct the issue is related to rpath. When CMake constructs
the rpath for the library linking it will have two paths (
/home/jenkins/workspace/FlightGear/dist/lib64,
/home/jenkins/workspace/SimGear/dist/lib64)
each that contain a copy of libosgText.so.130. CMake is warning that which
version of libosgText is undefined.

On Thu, Aug 24, 2017 at 10:08 AM, James Turner 
wrote:

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

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] Path to vc_redist

[Robert Maynard]

You can use the InstallRequiredSystemLibraries to do this. Since it sounds
like you don't want all the libraries installed, use
CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP and than deduce the path of
vc_redist.exe from the value(s) in CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS.

On Mon, Sep 4, 2017 at 3:01 AM, Roman Wüger  wrote:

> Hello,
>
> is there already an existing function to get the vc_redist.exe for the
> current generator?
>
> Regards
> Roman
> --
>
> 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
>
-- 

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] [ANNOUNCE] CMake 3.10.1 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.10.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.10.1 since 3.10.0:

Adam Ciarciński (1):
  bootstrap: Check support for unordered_map from compiler mode

Alexander Wittig (1):
  CPack: Fix macOS PKG component dependency information

Brad King (3):
  CUDA: Treat /usr/include as an implicit include directory
  server: Revert "Report backtraces in codemodel response"
  CMake 3.10.1

Christian Pfeiffer (4):
  FindMPI: Correct legacy variable handling
  FindMPI: Fix multiple configure runs
  FindMPI: Fix various legacy problems
  IRSL: Fix MSVC variable deferencing

Islam Amer (1):
  IAR: FindBinUtils should work for CXX as well as C

Matthew Woehlke (4):
  GoogleTest: Fix multiple discovery on same target
  GoogleTest: Improve gtest_discover_tests messages
  GoogleTest: Add timeout to discovery
  GoogleTest: Add test for missing test executable

Robert Maynard (1):
  CUDA: Shared libraries on Darwin properly setup @rpath install_names

Sebastian Holtermann (2):
  Autogen: Fix for AUTOMOC on macOS frameworks in CMake 3.10
  Autogen: Tests: Add test for MacOS frameworks

İsmail Dönmez (1):
  Clang: Do not mistake clang-cl 6.0 for GNU-like clang
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] "modern" CUDA handling and static libraries

[Robert Maynard]

Hi,

The CUDA_RESOLVE_DEVICE_SYMBOLS property was added for this exact
situation. You can find it documented at
https://cmake.org/cmake/help/v3.10/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html

Here is an example of it being used:
https://gitlab.kitware.com/cmake/cmake/commit/493671a5212c6548b2d7376c7065f5f76692a792#0eb128c2e695da6e4cedb9a408b108f117bd4fe3

On Tue, Dec 19, 2017 at 3:14 PM, Crni Gorac  wrote:
> Hello,
>
> My project is alike for what is described by following CMakeLists.txt
> for Cuda/Complex test case from CMake source distribution:
>
> #
> cmake_minimum_required(VERSION 3.8)
> project (CudaComplex CXX CUDA)
>
> string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
> set(CMAKE_CUDA_STANDARD 11)
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
> set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
>
> add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
> set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
> set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)
>
> add_library(CppLib STATIC dynamic.cpp mixed.cpp)
>
> add_executable(CudaComplex main.cpp)
> target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
> #
>
> So basically I want to build all my .cu files into one static library,
> and all my .cpp files (except for main.cpp) into another static
> library. These two libraries are then linked into main.cpp above. This
> works fine, and make output is:
>
> #
> Scanning dependencies of target CppLib
> Scanning dependencies of target CudaLib
> [  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
> [ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
> [ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
> [ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
> [ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
> [ 66%] Linking CXX static library libCppLib.a
> [ 66%] Built target CppLib
> [ 75%] Linking CUDA static library libCudaLib.a
> [ 75%] Built target CudaLib
> Scanning dependencies of target CudaComplex
> [ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
> [ 91%] Linking CUDA device code CMakeFiles/CudaComplex.dir/cmake_device_link.o
> [100%] Linking CXX executable CudaComplex
> #
>
> However, in my case these static libraries are actually to be
> delivered to a client.  The problem is that the dynamic linking of
> CUDA code (this is this line "Linking CUDA device code
> CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
> above) would still have to get done on client side, i.e. they would
> have to install CUDA SDK and provide that this step is accomplished
> through their build system.  So my question is: is it possible to
> somehow generate static library with CUDA code, using this new
> "...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
> completed on my side (note that on client side no CUDA code will be
> added to project)?
>
> Thanks.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] CMake Monthly Meeting Summary

[Robert Maynard]

Hi,

The next CMake monthly meeting will occur on Dec 5th at 10am in the
KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to
be added to the calendar invite don't hesitate to send me an email.

The next monthly meeting currently doesn't have a agenda yet, so
please suggest things to talk about. Currently on my list of items to
talk about is:
  - Setup a group of people to investigate the amount of work needed
to support C++20 modules
  - Should we schedule an internal CMake course
  - Keep working on blog articles

I wrote up some CMake 3.10 highlights slides which can be found at:
https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing

My goal with these slides is to have material to help people
disseminate new CMake features other Kitware teams and a keeping
collaborators informed. I plan on making these slides for every
significant CMake release.

As far as the blog to book goes the following action items have been organized:
- Bill is working on a blog post for December that will cover clang
tidy / use_what_you_include support in CMake
- Chuck/Robert/Bill are working on a CMake style guideline blog post
which is aiming for February
-- 

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 Monthly Meeting Summary

[Robert Maynard]

Sorry about this this was meant for an internal mailing list.

On Tue, Nov 21, 2017 at 12:11 PM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> Hi,
>
> The next CMake monthly meeting will occur on Dec 5th at 10am in the
> KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to
> be added to the calendar invite don't hesitate to send me an email.
>
> The next monthly meeting currently doesn't have a agenda yet, so
> please suggest things to talk about. Currently on my list of items to
> talk about is:
>   - Setup a group of people to investigate the amount of work needed
> to support C++20 modules
>   - Should we schedule an internal CMake course
>   - Keep working on blog articles
>
> I wrote up some CMake 3.10 highlights slides which can be found at:
> https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing
>
> My goal with these slides is to have material to help people
> disseminate new CMake features other Kitware teams and a keeping
> collaborators informed. I plan on making these slides for every
> significant CMake release.
>
> As far as the blog to book goes the following action items have been 
> organized:
> - Bill is working on a blog post for December that will cover clang
> tidy / use_what_you_include support in CMake
> - Chuck/Robert/Bill are working on a CMake style guideline blog post
> which is aiming for February
-- 

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] Handling of generator expressions

[Robert Maynard]

Hi Roberto,

Can you please report this as an issue (
https://gitlab.kitware.com/cmake/cmake ) as this looks like a bug in
the way we are parsing generator expressions in target_link_libraries.
The target_link_libraries fully supports taking a list of linker flags
when it isn't part of a generator expression.

On Sun, Nov 19, 2017 at 1:16 PM, Roberto Di Remigio
 wrote:
> Hello,
> I am trying to compile the following code snippet:
>
> int main(int argc, char ** argv) {
>   int stack_array[100];
>   stack_array[1] = 0;
>   return stack_array[argc + 100]; // BOOM
> }
>
> The followin CMakeLists.txt works fine, but you can notice that
> target_compile_options takes a list, while target_link_libraries takes a
> string. Always using the string will result in a compilation error, because
> the compiler flags are passed quoted to the compiler. Always using the list
> doesn't work either, because the generator expression is evaluated as
> $<1:-fsanitize=address -fno-omit-frame-pointer> and then passed as-is to the
> linker, which doesn't know what to do with it.
> Is this supposed to be like this? If yes, what's the rationale?
> Thanks in advance!
>   Roberto
>
> cmake_minimum_required(VERSION 3.3 FATAL_ERROR)
>
> project(recipe-09 CXX)
>
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CXX_EXTENSIONS OFF)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> list(APPEND CXX_BASIC_FLAGS "-g3" "-O1")
>
> include(CheckCXXCompilerFlag)
>
> set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer")
> set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS})
> check_cxx_compiler_flag(${ASAN_FLAGS} asan_works)
> unset(CMAKE_REQUIRED_FLAGS)
>
> add_executable(asan-example asan-example.cpp)
> string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS})
> target_compile_options(asan-example
>   PUBLIC
> ${CXX_BASIC_FLAGS}
> $<$:${_asan_flags}>
>   )
> target_link_libraries(asan-example
>   PUBLIC
> $<$:${ASAN_FLAGS}>
>   )
>
> --
>
> 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
-- 

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] CUDA support- no way to set GPUDebugInfo to be False ?

[Robert Maynard]

This is an oversight rather than an unsupported feature. Can you
report this as an issue on https://gitlab.kitware.com/cmake/cmake

On Fri, Dec 8, 2017 at 3:56 AM, Hancox, James  wrote:
> Hi,
>
>
>
> I’m working on porting an existing FindCUDA project over to using the new
> CMake built-in CUDA support, with Visual Studio 15.4.1, CUDA 9.0.176, and
> CMake 3.10.0. I am currently trying to find a way to disable the -G
> compilation flag for NVCC with Debug builds. (Due to the nature of our code,
> building with -G set takes an inordinately long time and still produces
> terrible debug info, so we prefer to leave it off- but we still want Debug
> builds so that we can easily debug CPU side code.)
>
>
>
> Unfortunately by default the Nvidia CUDA plugin for Visual Studio sets -G by
> default for debug builds. Disabling it requires the addition of
>
> false
>
>
>
> to the  section of the .vcxproj file. I can’t currently find
> any way to do this through Cmake. Have I missed something obvious, or is
> this not a supported feature?
>
>
>
> Many thanks,
>
> James Hancox
>
>
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.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
-- 

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] -std=c++17 vs -std=c++1y

[Robert Maynard]

If you have standard required enabled the compiler version shouldn't decay
down to 14 when asking for 17.

I recommend having a small test repo and using cmake --trace/--trace-expand
to determine where the gnu++1y is coming from. It is not clear when looking
at Modules/Compiler/Clang-CXX.cmake how gnu++1y would be used unless CMake
is thinking you are asking for C++14 on clang 3.5.
On Sun, May 6, 2018 at 1:35 PM Andrew Brownsword <
andrew.e.brownsw...@gmail.com> wrote:

> Well, I am specifying:

> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_CXX_STANDARD 17)
> set(CMAKE_CXX_EXTENSIONS ON)

> and the compiler line contains “-std=gnu++1y”.  I’m using a very recent
source build of CLang and libc++.  Any idea why cmake would fall back to 1y
in this case?





> On May 6, 2018, at 9:05 AM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> Note that c++17 is c++1z. c++1y was C++14.



> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name

> On Sun, May 6, 2018 at 5:00 PM, Andrew Brownsword <
andrew.e.brownsw...@gmail.com> wrote:

>> Hi,

>> Is there a way to get cmake 3.11 to emit 17 vs 1y when setting
CMAKE_CXX_STANDARD?  I’m finding that it seems to be a common practice to
use the value of the preprocessor define __cplusplus (which is a date), and
the value differs depending on whether 17 or 1y is used (at least with
CLang).  I haven’t figured out how to get cmake to emit -std=c++17, it
always seems to use 1y, which is causing problems with code that assumes
the __cplusplus date reflects the c++17 standardization date.

>> Thanks,
>> Andrew

>> --

>> 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:
>> https://cmake.org/mailman/listinfo/cmake



> --

> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

[Robert Maynard]

I recommend going with the custom target / custom command route.

On Fri, Apr 27, 2018 at 5:19 AM, Stephen McDowell 
wrote:

> Upon further inspection, it seems more related to PRE_BUILD.  The step to
> generating the files is through a add_custom_command call, which from the
> docs apparently may end up being PRE_LINK.
>
> I tried generating into the ${CMAKE_CURRENT_SOURCE}/include/nanogui,
> which will work for Makefiles but not for Ninja.
>
> So it seems that maybe this is not a pathing issue at all, but instead an
> order of operations issue.  If the Ninja generator ends up having this as
> PRE_LINK, the files haven’t been generated yet.
>
> That doesn’t quite explain why it worked previously, but perhaps the
> original setup was inherently flawed by relying on PRE_BUILD which is not a
> guaranteed order.
>
> Does anybody have thoughts on how to change things?  The files cannot be
> compiled on their own, but maybe I should instead create a fake target and
> make it a dependency of the real (object) library that needs them.  I keep
> messing that up, but this seems the most promising.
>
> -Stephen
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR

[Robert Maynard]

Here is how I would do this (
https://github.com/robertmaynard/Sandbox/tree/master/CMakeCustomCommandAfterTarget).
In my example the executable is the target I want to have a custom
PRE_BUILD step for.
On Sat, Apr 28, 2018 at 5:02 AM Stephen McDowell  wrote:


> After much deliberation, I was never successful in getting a synthetic
target to work as expected.  The dilemma is that `add_custom_command`
cannot specify both `TARGET` and `OUTPUT`, the work flow was something like

> add_custom_target(resource-dependency)
> add_custom_command(TARGET resource-dependency ... PRE_BUILD)
> add_custom_command(OUTPUT  DEPENDS
resource-dependency)
> ...
> add_library(actual-obj-library OBJECt  ...
others ...)
> add_dependencies(actual-obj-library resource-dependency)

> I'm sure that's a flawed approach, but in the end I realized I can
actually generate these files at *configure* time <3  The
add_custom_command was just a call to ${CMAKE_COMMAND} ...
resources/bin2c.cmake.  So in the end, it's actually a lot cleaner for us
to just include(resources/bin2c.cmake).

> I doubt this solution will be widely applicable to many projects, but if
you ever find yourself in a situation where you are doing
add_custom_command, where the custom command is calling ${CMAKE_COMMAND},
don't rely on PRE_BUILD because it's not a guarantee.  If you can, just
execute the script at configure time via an include(...) call.
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Forcing a target to be built if another target is built

[Robert Maynard]

That is roughly what I am saying. In my head you had a layout that looked
like

-> root_dir
--> module_A
--> tests_A
--> module_B
--> tests_B

So while it is tedious to have module_A explicitly add tests_A it would be
a possible solution. The problem is one of graph building.  Currently the
CMake 'all' graph properly represents building the active module and all
dependencies it needs. Separately you have a pool of smaller graphs that
represent all tests and targets that are from sub-directories that had
EXCLUDE_FROM_ALL applied. Nothing is quickly coming to me that will allow
you to add more components to the 'all' graph after the fact.

On Thu, May 17, 2018 at 6:19 AM Job Noorman <j...@noorman.info> wrote:

> I'm not sure I completely understand what you mean but I think your
> suggestion would be to list *all* needed subdirectories in the active
> project. This is not what a want. The active project simply lists its
> *direct* dependencies (via target_link_libraries) and CMake then figures
> out all the needed transitive dependencies.
>
> Please correct me if i missed your point :-)
>
>
> On 15/05/18 23:29, Robert Maynard wrote:
> >
> > Have you thought about not doing anything in the root CMakeLists for
> > your testing directories but instead inside the active project you use
> > add_subdirectory ( it supports relative paths to handle directories
> > not physically nested inside it ).
> >
> > On Wed, May 9, 2018 at 8:56 AM Job Noorman <j...@noorman.info
> > <mailto:j...@noorman.info>> wrote:
> >
> > Hi all,
> >
> > We have a large codebase consisting of 200+ modules. Each module is
> > defined in its own subdirectory and compiled as a static library.
> >
> > These modules are not final products on their own but are combined to
> > create "projects". We have about 15 projects that all use a subset of
> > the modules to implement their functionality. The projects are
> > independent in the sense that they cannot be built together; when
> > running cmake, we select the project to build.
> >
> > To ensure that only the modules that are needed by the selected
> > project
> > are built, we took the following approach: all modules have a common
> > root directory which is included using add_subdirectory with the
> > EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
> > added without this flag. This ensures that the targets defined by the
> > project and the modules that they need (but no other) are added to
> > the
> > build system. This works very well and is much nicer than having to
> > define options for all optional modules to be able to disable them.
> >
> > There is one catch, however: each module defines an executable
> > that runs
> > its unit tests. What should happen is that if a module is built by a
> > project, its unit tests are also built. However, there seems to be no
> > way to define this relationship in CMake. What we would like to
> > express
> > is that "if library A is built, then executable ATest should also be
> > built". Since ATest obviously links against A, we cannot use
> > add_dependencies(A ATest) since this creates a circular dependency
> > between an executable and a library.
> >
> > Note that the "option" approach briefly mentioned above would
> > allow us
> > to express this but this would be completely unwieldy in our case.
> >
> > Is there currently a way in CMake to express this relation between a
> > library and an executable?
> >
> > If not, would the following suggestion make sense?: A target property
> > "INTERFACE_DEPENDENCIES" could be added that would set the
> > MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting
> > this
> > property on A with ATest as value would then solve my problem
> > (note that
> > I proposed adding this property for a different use case here:
> > https://gitlab.kitware.com/cmake/cmake/issues/14633).
> >
> > Regards,
> > Job
> >
> > --
> >
> > Powered by www.kitware.com <http://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/su

Re: [CMake] include directories not found for object library

[Robert Maynard]

That is exactly how it will look.

On Wed, May 16, 2018 at 4:19 AM Miklos Espak <esp...@gmail.com> wrote:

> That's awesome, thanks a lot!
>
> So, it would look like this in my case then:
>
> target_link_libraries(baseapp PUBLIC dcmjpeg mylib1 mylib2)
>
> And the object library has to be added to the sources of the app1 and
> app2, like now. With other words, object libraries would be allowed on the
> left hand side of "target_link_libraries".
>
> This looks the most intuitive way, indeed.
>
> Cheers,
> Miklos
>
>
> On Tue, 15 May 2018 at 16:51, Robert Maynard <robert.mayn...@kitware.com>
> wrote:
>
>> This is scheduled to be fixed in the next release by allowing OBJECT
>> libraries to be used in target_link_libraries.
>>
>>
>>
>> On Tue, May 8, 2018 at 7:46 PM Miklos Espak <esp...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have an abstract class that I want to compile into many applications.
>>> Something like this:
>>>
>>> baseapp.h
>>> baseapp.cpp
>>> app1.h
>>> app1.cpp
>>> app2.h
>>> app2.cpp
>>> ...
>>>
>>> I thought of making an object library from baseapp because I want to
>>> compile it only once and it is used only internally.
>>>
>>> However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
>>> mylib2, and the include directories of these of these libraries are not
>>> found. For regular libraries and executables, the include directories are
>>> picked up from the target property of the linked libraries, but for object
>>> libraries you cannot specify target link libraries.
>>>
>>> I came up with this:
>>>
>>> add_library(baseapp OBJECT baseapp.h baseapp.cpp)
>>> target_include_directories(baseapp PUBLIC
>>>   $<TARGET_PROPERTY:dcmjpeg,INCLUDE_DIRECTORIES>
>>>   $<TARGET_PROPERTY:mylib1,INCLUDE_DIRECTORIES>
>>>   $<TARGET_PROPERTY:mylib2,INCLUDE_DIRECTORIES>)
>>>
>>> This works, but it does not look too pretty to me.
>>>
>>> I am wondering if there is a more elegant way.
>>>
>>> E.g. would it be a good idea to propagate the include dirs with the
>>> add_dependencies command? E.g. instead of the above, one could write:
>>>
>>> add_dependencies(baseapp dcmjpeg mylib1 mylib2)
>>>
>>> Cheers,
>>> Miklos
>>>
>>> --
>>>
>>> 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:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] include directories not found for object library

[Robert Maynard]

This is scheduled to be fixed in the next release by allowing OBJECT
libraries to be used in target_link_libraries.



On Tue, May 8, 2018 at 7:46 PM Miklos Espak  wrote:

> Hi,
>
> I have an abstract class that I want to compile into many applications.
> Something like this:
>
> baseapp.h
> baseapp.cpp
> app1.h
> app1.cpp
> app2.h
> app2.cpp
> ...
>
> I thought of making an object library from baseapp because I want to
> compile it only once and it is used only internally.
>
> However, baseapp depends on other libraries, e.g. dcmjpeg, mylib1 and
> mylib2, and the include directories of these of these libraries are not
> found. For regular libraries and executables, the include directories are
> picked up from the target property of the linked libraries, but for object
> libraries you cannot specify target link libraries.
>
> I came up with this:
>
> add_library(baseapp OBJECT baseapp.h baseapp.cpp)
> target_include_directories(baseapp PUBLIC
>   $
>   $
>   $)
>
> This works, but it does not look too pretty to me.
>
> I am wondering if there is a more elegant way.
>
> E.g. would it be a good idea to propagate the include dirs with the
> add_dependencies command? E.g. instead of the above, one could write:
>
> add_dependencies(baseapp dcmjpeg mylib1 mylib2)
>
> Cheers,
> Miklos
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] target_link_libraries and Custom Properties

[Robert Maynard]

>  I also wasn't able to find a way to get a list of targets a given target
depends on, so that I could run through it and query each dependent
target's custom property manually.

This isn't currently possible.

> The executable targets need to collect the shader files and headers of
only the libraries they depend on in order to compile them

Have you looked at using `target_sources`? In general target_sources are
transitive and allow you to include source files for compilation for your
consumers, when you combine them generator expressions you make the
inclusion conditional. A great example would be how Qt5 conditionally
includes sources when it encounters an executable on windows (
https://github.com/qt/qtbase/blob/17b73b0d2b8e0d643bdf13b543cc23d657a4b330/src/corelib/Qt5CoreConfigExtras.cmake.in#L160
).

On Wed, May 9, 2018 at 11:55 AM Marek Vojtko (Firaxis) <
marek.voj...@firaxis.com> wrote:

> Hi,
>
> I have multiple library targets that each provide shader files and
> headers. I also have multiple executable targets that each depend on a
> different set of these library targets. The executable targets need to
> collect the shader files and headers of only the libraries they depend on
> in order to compile them.
>
> The ideal solution would be to reproduce the transitive dependency
> behavior controlled by target_link_libraries on a custom target property
> [0], but as far as I can tell define_property does not do that - it just
> creates a property on a target that can be queried but is not part of the
> dependency chain. I also wasn't able to find a way to get a list of targets
> a given target depends on, so that I could run through it and query each
> dependent target's custom property manually.
>
> Variables do not solve this problem, because different executables depend
> on different libraries. Each library would need to know a) about all
> executables, and b) whether a particular executable depended on said
> library in order to be able to add the shader files and headers to a
> per-executable variable.
>
> Is there a way to achieve this in CMake?
>
> [0] CMake has a set of properties that get propagated according to the
> transitive dependency rules (PRIVATE, INTERFACE, PUBLIC) using
> target_link_libraries (e.g. COMPILE_DEFINITIONS, COMPILE_OPTIONS,
> INCLUDE_DIRECTORIES, etc.). I would like to add a custom property, for
> example SHADER_SOURCES, and have it propagate the same way, i.e. target A
> that depends on targets B, C, and D would have the INTERFACE_SHADER_SOURCES
> of targets B, C, and D in its SHADER_SOURCES property.
> --
> Marek Vojtko
> mail: marek.voj...@firaxis.com
> phone: (+1) 410-229-2519
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.11.2 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.11.2 is now available for download.

Please use the latest release from our download page:
   https://cmake.org/download/

* Calling "add_library()" to create an alias of an imported target
   that is not globally visible now causes an error again as it did
   prior to 3.11.0.  This diagnostic was accidentally dropped from
   CMake 3.11.0 and 3.11.1 by the change to allow globally visible
   imported targets to be aliased.

* The "FindQt4" module "qt4_wrap_cpp", "qt4_wrap_ui" and
   "qt4_add_resources" macros now set "SKIP_AUTOMOC" and "SKIP_AUTOUIC"
   on their generated files.  These files never need to be processed by
   moc or uic, and we must say so explicitly to account for policy
   "CMP0071".

Thanks for your support!

-
Changes in 3.11.2 since 3.11.1:

Brad King (8):
   Ninja: Do not add empty custom command for file(GENERATE) outputs
   C++ feature checks: Filter out warnings caused by local configuration
   libuv: linux/sparc64: use fcntl to set and clear O_NONBLOCK
   FindCUDA: Fix regression in separable compilation without cublas
   FindBoost: Remove extra indentation in 1.65/1.66 dependency block
   add_library: Restore error on alias of non-global imported target
   add_custom_{command,target}: Fix crash on empty expanded command
   CMake 3.11.2

Christian Pfeiffer (1):
   IRSL: Fix Intel library list for ifort-only setups

Christof Krüger (1):
   InstallRequiredSystemLibraries: Check for existence of mfcm dlls

Filip Matzner (1):
   FindBoost: Backport versioned python dependencies for v1.35 to v1.66

Marc Chevrier (5):
   Fix CMAKE_DISABLE_SOURCE_CHANGES recognition of top of build tree
   FindJava, FindJNI, UseJava: update for version 10 support
   FindJava, FindJNI: Ensure most recent version is searched first
   FindJava, FindJNI: fix erroneous regex, enhance registry lookup
   Help: Specify COMPILE_OPTIONS and COMPILE_FLAGS source properties
   usage

Matthew Woehlke (2):
   Qt4Macros: Use get_property/set_property
   Qt4Macros: Don't AUTOMOC or AUTOUIC qt4-generated files

Rolf Eike Beer (2):
   FindPkgConfig: do not unset unused variable
   FindBLAS: do not write an imported target name into BLAS_LIBRARIES

Sebastian Holtermann (1):
   Autogen: Register generated dependency files
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Install libraries defined in INTERFACE targets

[Robert Maynard]

BUILD_INTERFACE explicitly means that only consumers inside the same
buildsystem should use these libraries. To specify the libraries that
should be used when linking to an installed version of a library you need
to use INSTALL_INTERFACE.

The reason for BUILD and INSTALL interface is to make sure you can build
relocatable libraries and not embed absolute paths into a libraries
specification.

On Wed, May 16, 2018 at 7:03 AM  wrote:

> Hallo,
> I have created a simple project simulating the issue.
>
> There is 'run.sh' script which first builds an executable using
> 'add_subdirectory()' CMake command. It works without issues, as expected
> (the libraries required by Module1 and Module2 are passed to the Module4
> builder).
> Then, it first builds a STATIC library (defined by Module3) which is then
> used by Module4. This fails, since I do not know how to export a list of
> libraries required by Module1 and Module2.
>
> Could someone, please, look at the project (which is really simple) and
> give me a hint how Module3 should export (when install iss called) a CMake
> script, which would containt the libraries to link with?
>
> Thank you very much.
> Best regards,
>
> Dan
>
>
> __
> > Od: 
> > Komu: 
> > Datum: 04.05.2018 13:25
> > Předmět: Install libraries defined in INTERFACE targets
> >
>
>  Hello,
>  I build a project which consists of several "modules" with various mutual
> dependencies. Each module defines its OBJECT target as:
>
>
>  # Module 1:
>  add_library(Module1 OBJECT )
>  target_include_directories(Module1 PRIVATE
> ${CMAKE_CURRENT_SOURCE_DIR})
>
>  add_library(Module1_LIBRARIES INTERFACE)
>  target_link_libraries(Module1_LIBRARIES INTERFACE
> $)
>
>
>  # Module 2:
>  add_library(Module2 OBJECT )
>  target_include_directories(Module2 PUBLIC
> $)
>
>  add_library(Module2_LIBRARIES INTERFACE)
>  target_link_libraries(Module2_LIBRARIES INTERFACE
> $ $)
>
>  add_library(Module2_INCLUDES  INTERFACE)
>  target_include_directories(Module2_INCLUDES  INTERFACE
> $)
>  target_sources(Module2_INCLUDES  INTERFACE )
>
>  add_library(Module_CONFFILE  INTERFACE)
>  target_sources(Module2_CONFFILE  INTERFACE Module.config)
>
>
>  And when building a final product (or one of the final products), I use
> the individual targets:
>
>  add_library(Product1 STATIC $
> $ ...)
>  target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES
> $ $
> ...)
>
>
>
>  It works perfectly, the library is built using all the sources. Even when
> defining INSTALL, all the properties of the targets (include files, config
> files, etc.) can be accessed and are installed correctly
>
>  install(TARGETS Product1  DESTINATION "./" EXPORT "libProduct1")
>  install(FILES $
> DESTINATION "./config")
>  install(FILES $
> DESTINATION "./include")
>
>
>  The problem starts when I want to export a CMake file listing all the
> libraries which were defined by the individual modules (and are accessed by
> $) since they know what they need (how
> they were configured).
>
>  When building a static library (which is shown here), I need to export a
> list of additional libraries necessary to link the Product1 correctly. But
> using $ in the INSTALL() command does
> not work, neither works something like:
>
>  install(EXPORT "llibProduct1" DESTINATION "."
> EXPORT_LINK_INTERFACE_LIBRARIES)
>
>
>  So the question is: how to export the libraries defined by the individual
> modules to an CMake file which would be installed together with the
> Product1 library and header files?
>
>
>  Thank you very much,
>  Dan
>
>  P.S. I use CMake 3.6.2.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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: 

Re: [CMake] Forcing a target to be built if another target is built

[Robert Maynard]

Have you thought about not doing anything in the root CMakeLists for your
testing directories but instead inside the active project you use
add_subdirectory ( it supports relative paths to handle directories not
physically nested inside it ).

On Wed, May 9, 2018 at 8:56 AM Job Noorman  wrote:

> Hi all,
>
> We have a large codebase consisting of 200+ modules. Each module is
> defined in its own subdirectory and compiled as a static library.
>
> These modules are not final products on their own but are combined to
> create "projects". We have about 15 projects that all use a subset of
> the modules to implement their functionality. The projects are
> independent in the sense that they cannot be built together; when
> running cmake, we select the project to build.
>
> To ensure that only the modules that are needed by the selected project
> are built, we took the following approach: all modules have a common
> root directory which is included using add_subdirectory with the
> EXCLUDE_FROM_ALL flag. Then, the current project's root directory is
> added without this flag. This ensures that the targets defined by the
> project and the modules that they need (but no other) are added to the
> build system. This works very well and is much nicer than having to
> define options for all optional modules to be able to disable them.
>
> There is one catch, however: each module defines an executable that runs
> its unit tests. What should happen is that if a module is built by a
> project, its unit tests are also built. However, there seems to be no
> way to define this relationship in CMake. What we would like to express
> is that "if library A is built, then executable ATest should also be
> built". Since ATest obviously links against A, we cannot use
> add_dependencies(A ATest) since this creates a circular dependency
> between an executable and a library.
>
> Note that the "option" approach briefly mentioned above would allow us
> to express this but this would be completely unwieldy in our case.
>
> Is there currently a way in CMake to express this relation between a
> library and an executable?
>
> If not, would the following suggestion make sense?: A target property
> "INTERFACE_DEPENDENCIES" could be added that would set the
> MANUALLY_ADDED_DEPENDENCIES target property of dependents. Setting this
> property on A with ATest as value would then solve my problem (note that
> I proposed adding this property for a different use case here:
> https://gitlab.kitware.com/cmake/cmake/issues/14633).
>
> Regards,
> Job
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.11.4 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.11.4 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.11.4 since 3.11.3:

Brad King (2):
  Windows: Restore support for running CMake through a symlink
  CMake 3.11.4

Jean-Christophe Fillion-Robin (1):
  ExternalProject: Fix cache generation when args end with "-NOTFOUND"

Matt McCormick (1):
  ExternalProject: Improve URL_HASH argument description
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Upcoming AMA on CMake

[Robert Maynard]

On June 20th, I plus other Kitware CMake contributors will be doing an
AMA on reddit ( r/cpp ). So please ask us any questions about CMake,
contributing to CMake, or just life in general.
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.0-rc1 is ready for testing

[Robert Maynard]

I am proud to announce the first CMake 3.12 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.12

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.12/release/3.12.html

Some of the more significant changes in CMake 3.12 are:

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "Compile Features" functionality is now aware of C++ 20.  No
  specific features are yet enumerated besides the "cxx_std_20" meta-
  feature.

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* A new "$" and "$"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$" "generator expression" has been
  added.

* A new "$" "generator expression" has
  been added.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.


CMake 3.12 Release Notes


Changes made since CMake 3.11 include the following.


New Features



Generators
--

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.


Command-Line


* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.


Commands


* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
  to expose "TOUCH" functionality without having to use CMake's
  command- line tool mode with "execute_process()".

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* The "install()" command learned an optional "NAMELINK_COMPONENT"
  parameter, which allows you to change the component for a shared
  library's namelink. If none is specified, the value of "COMPONENT"
  is used by default.

* The "list()" command learned a "JOIN" sub-command to concatenate
  list's elements separated by a glue string.

* The "list()" command learned a "SUBLIST" sub-command to get a
  sublist of the list.

* The "list()" command learned a "TRANSFORM" sub-command to apply
  

Re: [CMake] Install libraries defined in INTERFACE targets

[Robert Maynard]

Here is an updated version of your example with working exporting of
Module3 and importing inside Module4 ( I ignored the XML lib importing
)


CMake_with_exporting.tar.xz
Description: application/xz
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Is there a way to obtain the current compiler standard flag?

[Robert Maynard]

I am pretty sure you currently can't extract the compile flag information.
This would be an enhancement and would have to be done as a generator
expression.
On Tue, May 29, 2018 at 5:37 PM Chris Green  wrote:

> Hi,

> We have to use a utility (Root's rootcling/genreflex tool) as part of a
> custom command to parse some C++ headers. We are in the process of
> migrating from using raw -std= additions to compilation flags to use of
> CMAKE_CXX_STANDARD and friends. We need to pass the correct compiler
> flag to the invocation of rootcling in order to ensure headers are
> parsed correctly based on the CXX_STANDARD and CXX_EXTENSIONS
> properties, but we don't appear to be able to discover what it is. We
> could generate it from scratch like we did before, but it seems like it
> would be preferable to be able to pass it to the command as already
> calculated by CMake, perhaps via a generator expression.

> Is there some way to do this already that I missed, or would this be an
> enhancement?

> Thanks,

> Chris.

> --

> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.11.3 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.11.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.11.3 since 3.11.2:

Brad King (3):
  cmSystemTools: Revert GetRealPath implementation on Windows
  CPack: Fix cross-compilation of WiX generator
  CMake 3.11.3

Sander Vrijders (1):
  TestDriver: Replace strncpy with strcpy
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] how to deprecate a target?

[Robert Maynard]

I am not aware of a nice way to setup CMake to error out if a user
links to `foo` instead of `Foo::foo`.
On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve  wrote:
>
> Hi all,
>
> Consider this situation.  I'm building a Foo packaged, to be used by a
> Bar project.
>
> Foo used to export its target as simply foo.
> Now it exports its target as Foo::foo.
>
> Bar contains this:
> add_library(bar ...)
> target_link_libraries(bar foo)
>
> This of course must now be:
> add_library(bar ...)
> target_link_libraries(bar Foo::foo)
>
> But if bar still links to the foo instead of Foo::foo, then CMake
> doesn't really complain.  foo doesn't exist, but configures and
> generates just fine.  Of course, you'll face strange build errors, from
> which it isn't immediately apparent what's causing this ...
>
> How can I make sure CMake will complain loudly when bar still links to foo?
>
> Thanks,
> Bram.
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

[Robert Maynard]

I am proud to announce the second CMake 3.12 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.12

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.12/release/3.12.html

Some of the more significant changes in CMake 3.12 are:

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.

* The "target_link_libraries()" command may now be called to modify
  targets created outside the current directory.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "Compile Features" functionality is now aware of C++ 20.  No
  specific features are yet enumerated besides the "cxx_std_20" meta-
  feature.

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* A new "$" and "$"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$" "generator expression" has been
  added.

* A new "$" "generator expression" has
  been added.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.


CMake 3.12 Release Notes


Changes made since CMake 3.11 include the following.


New Features



Generators
--

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.


Command-Line


* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.


Commands


* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
  to expose "TOUCH" functionality without having to use CMake's
  command- line tool mode with "execute_process()".

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* The "install()" command learned an optional "NAMELINK_COMPONENT"
  parameter, which allows you to change the component for a shared
  library's namelink. If none is specified, the value of "COMPONENT"
  is used by default.

* The "list()" command learned a "JOIN" sub-command to concatenate
  list's elements separated by a glue string.

* The "list()" command learned a "SUBLIST" sub-command to get a
  sublist of the list.

* The "list()" command learned a "TRANSFORM" sub-command to apply
 

Re: [CMake] ccmake command missing from 3.12.0 RC releases

[Robert Maynard]

Thanks for reporting this. I am looking into it.
On Sun, Jul 1, 2018 at 6:18 PM Miklos Espak  wrote:
>
> Hi,
>
> the 'ccmake' command seems to be missing from the linux tarballs from 3.12.0 
> RC1 and RC2. Not sure if you are aware of that.
>
> The release notes does not mention that it should be removed, so I hope the 
> final release is going to have it. :)
>
> Maybe the curses dev package isn't installed on the build machine?
>
> Cheers,
> Miklos
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing

[Robert Maynard]

> Users of the old function cannot use the new syntax in older cmake versions

The new cmake_minimum_required syntax of MIN...POLICY_MAX is entirely
backwards compatible and will just be ignored by cmake < 3.12.
On Sat, Jun 30, 2018 at 1:14 AM Hendrik Sattler  wrote:
>
> It would actually make even more sense to rename cmake_minimum_required() to 
> cmake_version_required() with the new syntax or something similar. Users of 
> the old function cannot use the new syntax in older cmake versions and the 
> old name does not actually fit the new functionality.
>
>
> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" 
> :
> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
> >[...]
> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
> >>  commands now accept a version range using the form
> >>  "[...]". The "" version is required but policies are
> >>  set based on the "" version.  This allows projects to specify a
> >>  range of versions for which they have been updated and avoid
> >>  explicit policy settings.
> >[...]
> >
> >I suggest the following change to the above description:
> >
> >but policies are set based on the "" version.
> >
> >==>
> >
> >but policies are set based on the minimum of the running CMake and
> >"" versions.
> >
> >I prefer the latter because it immediately answers the question implied
> >by the former, i.e.,
> >what happens if the running version is less than max?
> >
> >Alan
> >__
> >Alan W. Irwin
> >
> >Programming affiliations with the FreeEOS equation-of-state
> >implementation for stellar interiors (freeeos.sf.net); the Time
> >Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> >software package (plplot.sf.net); the libLASi project
> >(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> >and the Linux Brochure Project (lbproject.sf.net).
> >__
> >
> >Linux-powered Science
> >__
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Green Hills MULTI generator development

[Robert Maynard]

An easy way to track the activity and authors is to look at the
history on the generator.
 ( 
https://gitlab.kitware.com/cmake/cmake/commits/master/Source/cmGlobalGhsMultiGenerator.cxx
)
On Thu, Jun 21, 2018 at 9:06 AM Erich Schroeter
 wrote:
>
> Is anyone actively developing the Green Hills MULTI generator support? If so, 
> who can I contact to get involved?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Multiple cross compiling

[Robert Maynard]

Currently CMake only supports a single platform / toolchain per build directory.

If you need to build with multiple toolchains you will need to use
some form of a wrapper. Which can either be an external script that
invokes CMake multiple times or a CMake project that uses
ExternalProject (
https://cmake.org/cmake/help/latest/module/ExternalProject.html )


On Mon, Jan 8, 2018 at 2:44 PM, szymon zakrent  wrote:
> Is there a way to make cmake cross compile automatically for multiple
> platforms at the same time without running cmake multiple times with
> different toolchains?
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I create a C executable and C++ library from the same source

[Robert Maynard]

As stated CMake tracks source files globally so they can only have a single
language.

Project that I work on have migrated over to using file(GENERATE) to
produce the files as it only
requires a couple lines of CMake code.

get_filename_component(c_fname "${c_source_file}" NAME_WE)
get_filename_component(c_fullpath "${c_source_file}" ABSOLUTE)
file(GENERATE
  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${c_fname}.cpp
  CONTENT "#include \"${c_fullpath}\"")

What ever approach you take I recommend not using an approach that copies
the contents of the
source file itself. Those will generally than require CMake to re-run every
time you modify the file. Instead
use an include statement so CMake won't re-run.

On Wed, Jan 17, 2018 at 1:29 PM, J Decker  wrote:

> No.
> CMake tracks each source file name exactly once.  If you set properties on
> it, it will be treated that way always.  Have to make  a copy of the source
> to cpp...
>
> copies to cmake_binary_dir/
> plusplus_file_dup is the resulting list
> ( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L655 )
>
> (really this is just for headers... src/csrc.h should be
> ${binary}/src/csrc.h in target too because #include "crsc.h"
>
> FOREACH(SOURCE ${PLUSPLUS_FILES_TO_COPY})
>if( ${SOURCE} MATCHES "${SOURCES_ROOT}(.*)$" )
>set( BASENAME ${CMAKE_MATCH_1} )
>set( plusplus_file_dup ${plusplus_file_dup} 
> ${CMAKE_BINARY_DIR}/${BASENAME}
> )
>add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}
>DEPENDS ${SOURCE}
>COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}
>#COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}
>)
>else()
>endif()
> ENDFOREACH(SOURCE)
>
>
> -
> ( https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L672 )
> THis make s abetter copy routine; it tests to see the type of header(file)
> and possible substitutions...  still kinda some debugging coments (#)  in
> there... this adds it as a rule, so it only generates the target source if
> the source is referenced.  therefore also onlly when those C files change
> do new copies get made.
>
> macro( COPY_CPLUSPLUS FILE_LIST )
> FOREACH(SOURCE ${ARGN} )
>if( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.c$" )
>   set( FILEOK 1 )
>   set( BASENAME ${CMAKE_MATCH_1} )
>   set( FILEEXT .cpp )
>elseif( ${SOURCE} MATCHES "${SACK_BASE}/(.*)\\.h$" )
>   set( FILEOK 1 )
>   set( BASENAME ${CMAKE_MATCH_1} )
>   set( FILEEXT .h )
>elseif( ${SOURCE} MATCHES "(.*)\\.c$" )
>   set( FILEOK 1 )
>   set( BASENAME ${CMAKE_MATCH_1} )
>   set( FILEEXT .cpp )
>elseif( ${SOURCE} MATCHES "(.*)\\.h$" )
>   set( FILEOK 1 )
>   set( BASENAME ${CMAKE_MATCH_1} )
>   set( FILEEXT .h )
>else()
>   set( FILEOK 0 )
>   set( BASENAME "" )
>endif()
>
>if( FILEOK )
>get_source_file_property(SOURCE_FOLDER ${SOURCE} FOLDER)
>
>if( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
>   if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
> #message( "err folder : ${SOURCE_FOLDER} " )
> SOURCE_GROUP( ${SOURCE_FOLDER} FILES ${SOURCE} )
> SOURCE_GROUP( ${SOURCE_FOLDER} FILES 
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>   endif()
>   add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${
> BASENAME}${FILEEXT}
>   DEPENDS ${SOURCE}
>   COMMAND ${CMAKE_COMMAND} -E
> copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>   #COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>   )
>   #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different ${SOURCE}
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} )
>
>else( ${SOURCE} MATCHES "^${PROJECT_SOURCE_DIR}.*" )
>  if( NOT ${SOURCE_FOLDER} MATCHES "NOTFOUND" )
>#message( "err folder : ${SOURCE_FOLDER} " )
>SOURCE_GROUP( ${SOURCE_FOLDER} FILES 
> ${PROJECT_SOURCE_DIR}/${SOURCE}
> )
>SOURCE_GROUP( ${SOURCE_FOLDER} FILES 
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>  endif()
>  add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${
> BASENAME}${FILEEXT}
>  DEPENDS ${PROJECT_SOURCE_DIR}/${SOURCE}
>  COMMAND ${CMAKE_COMMAND} -E copy_if_different
> ${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>  #COMMAND ${CMAKE_COMMAND} -E touch
> ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
>  )
>  #EXECUTE_PROCESS(COMMAND cmake -E copy_if_different
> ${PROJECT_SOURCE_DIR}/${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT}
> )
>  #message( "LIB2_SOURCE2 : 

[CMake] [ANNOUNCE] CMake 3.10.2 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.10.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.10.2 since 3.10.1:

Brad King (2):
  KWIML: Backport RISC-V update to CMake 3.10
  CMake 3.10.2

Egor Pugin (1):
  FindPostgreSQL: Add support for PG10

Joel T. Frederico (1):
  cmGraphVizWriter: Updated to create and follow dependers for
  interface targets

Sebastian Holtermann (2):
  Autogen: Fix for problematic nested list separator
  Autogen: Ignore not existing source files in cmMakefile
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Recommandation for macOS framework install rules

[Robert Maynard]

Are you just checking if the compiler is GCC? if so I would use
COMPILER_ID 
https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER_ID.html

On Wed, Jan 17, 2018 at 6:19 PM, J Decker  wrote:
> It's not entirely related other than Mac
>
> I had to test
>
> if( __COMPILER_GNU AND NOT CMAKE_COMPILER_IS_GNUCC )
>
> instead of just CMAKE_COMPILER_IS_GNUCC (which was unset)
>
> __COMPILER_GNU was found after doing a dump...
>
> I suppose there's some modern way I'm supposed to test GCC that works on all
> systems?
>
>
> On Wed, Jan 17, 2018 at 2:49 PM, Lucas Soltic 
> wrote:
>>
>> Hello,
>>
>> By default library install() command uses CMAKE_INSTALL_PREFIX (/usr/local
>> by default) as a base for relative install paths. But when you define
>> install rules for macOS frameworks, it doesn't make much sense to install
>> them there. I'd rather expect something like /Library/Frameworks.
>>
>> On the other side, if you have more things to install like a "readme" or
>> documentation that should go into /usr/local/share, it doesn't make sense to
>> have them installed in /Library/Frameworks. So you can't just change
>> CMAKE_INSTALL_PREFIX to be /Library/Frameworks.
>>
>> What do you recommend to keep installation rules simple (ie. remain
>> relative) and yet support installation of both frameworks and other things?
>>
>> Best regards,
>> Lucas
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Confusion with range-based FOREACH logic

[Robert Maynard]

Hi,

Looking at the documentation for 'RANGE' indicates that it is
inclusive on both ends (but poorly), which as you point out is not
what most people will expect. To solve your problem you can subtract 1
from len before you loop to have the behavior you want.


On Tue, Jan 23, 2018 at 12:27 PM, Robert Dailey
 wrote:
> I am doing the following:
>
> ```
> set( CS_THIRD_PARTY_REFERENCES
> Iconic.Zip ${CMAKE_CURRENT_SOURCE_DIR}/DotNetZip/Iconic.Zip.dll
> )
>
> if( CS_THIRD_PARTY_REFERENCES )
> list( LENGTH CS_THIRD_PARTY_REFERENCES len )
> message( STATUS "len: ${len}" )
> foreach( i RANGE 0 ${len} 2 )
> message( STATUS "i: ${i}" )
> list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_name )
> math( EXPR i "${i}+1" )
> list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_path )
> set_property( TARGET ${target_name} PROPERTY
> VS_DOTNET_REFERENCE_${assembly_name} ${assembly_path}
> )
> message( STATUS "i: ${i}" )
> message( STATUS "assembly_name: ${assembly_name}" )
> message( STATUS "assembly_path: ${assembly_path}" )
> endforeach()
> endif()
> ```
>
> I am finding that the foreach() loops 2 times when ${len} is 2. What I
> expect during the 2nd iteration is that it does ${i}+STEP (0+2) which
> would equal 2, and so long as 2<${len} (2<2), then it would continue
> to iterate. In this case, it should stop after the first iteration.
> I'm thinking that this should work like a C++ for loop. Is this not
> the case? How should I be iterating over a list of 2 times at a time?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake detects suspicious compiler

[Robert Maynard]

Have you tried running with '--trace-expand' with a clean build
directory? I would start by looking for where the execute_process
occurs that verifies the C compiler and work backwards from that
point.

On Mon, Jan 29, 2018 at 5:45 AM, christoph@ruediger.engineering
 wrote:
> Oh, sorry. I meant it survives `hash -r`.
>
>
>
> rüdiger.engineering
>
> Christoph Rüdiger
>
> Düsseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
> Von: CMake  im Auftrag von
> "christoph@ruediger.engineering" 
> Datum: Montag, 29. Januar 2018 um 11:45
> An: Don Hinton 
>
>
> Cc: "cmake@cmake.org" 
> Betreff: Re: [CMake] CMake detects suspicious compiler
>
>
>
> Sadly, it’s not a cache issue. The behavior survives `hash -h` and exists
> also in a clean new shell. Any other ideas?
>
>
>
> Regards
>
> Christoph
>
>
>
> rüdiger.engineering
>
> Christoph Rüdiger
>
> Düsseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
> Von: Don Hinton 
> Datum: Freitag, 26. Januar 2018 um 20:48
> An: "christoph@ruediger.engineering" 
> Cc: "cmake@cmake.org" 
> Betreff: Re: [CMake] CMake detects suspicious compiler
>
>
>
> Sounds like it might be a shell cache issue.
>
>
>
> https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables
>
>
>
>
>
> On Fri, Jan 26, 2018 at 10:30 AM, christoph@ruediger.engineering
>  wrote:
>
> Hi,
>
>
>
> I’ve one Linux system here, where cmake always detects a C compiler from a
> cross-toolchain. Doesn’t sound strange up to now, but the real deal is that
> the path to the compiler is totally unknown to the shell. It is not in PATH,
> CC and CXX env variables are empty and CMAKE_C_COMPILER and
> CMAKE_CXX_COMPILER are not set. The build server is used by multiple users
> and all but one can use cmake without issues. So I assume that it is some
> kind of per-user setting.
>
>
>
> Does anyone have a hint for me where to continue digging?
>
>
>
> The detected compiler path looks a bit like cmake is automatically pulling a
> toolchain file, without having any toolchain file specified on the command
> line. Is there some mechanism for specifying a default toolchain file, i.e.
> via environment variable or config file?
>
>
>
> Regards
>
> Christoph
>
>
>
> --
>
> rüdiger.engineering
>
> Christoph Rüdiger
>
> Düsseldorfer Str. 12
>
> 45145 Essen
>
> Germany
>
>
>
> phone: +49 201 458 478 58
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Config.cmake.in: Conditionally serve static or shared library

[Robert Maynard]

If you want to support consumers that are building shared and static
libraries themselves you can do this by using an import library with a
generator expression.
A simplified version of how do this, besides the import library can be found at:

https://github.com/robertmaynard/Sandbox/blob/master/CMakeInterfaceChangesLibrary/CMakeLists.txt

On Wed, Feb 14, 2018 at 11:34 AM, ThePhD  wrote:
> I think you can use what's called an "Alias Library":
> https://cmake.org/cmake/help/latest/command/add_library.html#alias-libraries
>
> if (BUILD_SHARED_LIBS)
>  add_library(my_libprimesieve ALIAS libprimesieve)
> else
>  add_library(my_libprimesieve ALIAS libprimesieve-static)
> endif(BUILD_SHARED_LIBS)
>
> Then, set it properly to Primesieve::Primesieve and it should work.
>
>
> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch  wrote:
>>
>> Hi,
>>
>> My primesieve project builds as both a static and a shared library, hence
>> there are 2 targets in my main CMakeLists.txt:
>>
>> 1) libprimesieve (shared library)
>> 2) libprimesieve-static
>>
>> I am now trying to add support for find_package(Primesieve). Ideally I
>> would like that users can link against libprimesieve as follows:
>>
>> find_package(Primesieve REQUIRED)
>> target_link_libraries(user_library Primesieve::Primesieve)
>>
>> And I want Primesieve::Primesieve to be an alias for
>> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
>> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
>> BUILD_SHARED_LIBS=OFF (or if it is not set).
>>
>> Is this possible?
>> Do you know any library that has already implemented this?
>>
>> Thanks,
>> Kim
>>
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Config.cmake.in: Conditionally serve static or shared library

[Robert Maynard]

It would be really nice though if CMake would support library aliases for
import targets, then I could achieve the same using much nicer code.

3.11 will include support for aliasing import targets, as long as the
import target was marked with GLOBAL visibility.

On Wed, Feb 14, 2018 at 3:47 PM, Kim Walisch  wrote:
> Thanks, I got it working!
>
> Unfortunately I could not make the generator expression work inside
> PrimesieveConfig.cmake.in, here is the error message:
>
> CMake Error:
>   Error evaluating generator expression:
> $
>   Expression did not evaluate to a known generator expression
>
> Note that in my main CMakeLists.txt the generator expression worked
> fine. But I figured out I don't actually need the generator expression,
> the following code inside my PrimesieveConfig.cmake.in does the trick:
>
> if(BUILD_SHARED_LIBS)
> add_library(Primesieve::Primesieve INTERFACE IMPORTED)
> set_target_properties(Primesieve::Primesieve PROPERTIES
> INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve")
> else()
> add_library(Primesieve::Primesieve INTERFACE IMPORTED)
> set_target_properties(Primesieve::Primesieve PROPERTIES
> INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve-static")
> endif()
>
> This trick is also used by the c-ares library:
> https://github.com/gjasny/c-ares/blob/fec405a420597180244e6c66912f09ae84b31123/c-ares-config.cmake.in
>
> The trick was already discussed on the cmake mailing list before:
> https://cmake.org/pipermail/cmake-developers/2017-June/030115.html
>
> It would be really nice though if CMake would support library aliases for
> import targets, then I could achieve the same using much nicer code.
>
> Kim
>
> On Wed, Feb 14, 2018 at 7:08 PM, Kim Walisch  wrote:
>>
>> CMake currently does not allow alias libraries for import targets:
>>
>> $ cmake ..
>> CMake Error at /usr/local/lib/cmake/primesieve/PrimesieveConfig.cmake:7
>> (add_library):
>>   add_library cannot create ALIAS target "my_libprimesieve" because target
>>   "Primesieve::libprimesieve-static" is IMPORTED.
>> Call Stack (most recent call first):
>>   CMakeLists.txt:6 (find_package)
>>
>> -- Configuring incomplete, errors occurred!
>>
>> Kim
>>
>>
>> On Wed, Feb 14, 2018 at 5:34 PM, ThePhD  wrote:
>>>
>>> I think you can use what's called an "Alias Library":
>>> https://cmake.org/cmake/help/latest/command/add_library.html#alias-libraries
>>>
>>> if (BUILD_SHARED_LIBS)
>>>  add_library(my_libprimesieve ALIAS libprimesieve)
>>> else
>>>  add_library(my_libprimesieve ALIAS libprimesieve-static)
>>> endif(BUILD_SHARED_LIBS)
>>>
>>> Then, set it properly to Primesieve::Primesieve and it should work.
>>>
>>>
>>> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch 
>>> wrote:

 Hi,

 My primesieve project builds as both a static and a shared library,
 hence
 there are 2 targets in my main CMakeLists.txt:

 1) libprimesieve (shared library)
 2) libprimesieve-static

 I am now trying to add support for find_package(Primesieve). Ideally I
 would like that users can link against libprimesieve as follows:

 find_package(Primesieve REQUIRED)
 target_link_libraries(user_library Primesieve::Primesieve)

 And I want Primesieve::Primesieve to be an alias for
 Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
 CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
 BUILD_SHARED_LIBS=OFF (or if it is not set).

 Is this possible?
 Do you know any library that has already implemented this?

 Thanks,
 Kim

 --

 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:
 https://cmake.org/mailman/listinfo/cmake

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

Re: [CMake] OBJECT Library Type

[Robert Maynard]

As the error message states an OBJECT library can't consume other
OBJECT libraries. When creating the actual library you will have to
explicitly state what $ you need.

If you are just looking at a way to simplify the logic for the
consuming library you should look at doing the following:

1. Use a global property to store what OBJECT targets should be consumed

2. Wait for https://gitlab.kitware.com/cmake/cmake/merge_requests/1524
to be finished.

On Fri, Feb 16, 2018 at 12:29 PM, Simone Atzeni  wrote:
> Hi,
>
>
>
> I am trying to merge together two “OBJECT” libraries.
>
> I am following the tutorial at:
> https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>
>
>
> However, in my case I have more level of folder nesting, and at the parent
> level I would like to merge two “OBJECT” libraries and only at the top I
> want to create the actual library.
>
>
>
> I tried with:
>
>
>
> add_library(common OBJECT "$ $
> $")
>
>
>
> But I get the following error:
>
>
>
> -
>
> CMake Error at lib/common/CMakeLists.txt:31 (add_library):
>
>   OBJECT library "common" contains:
>
>
>
> file1.cpp.o
>
> file2.cpp.o
>
> file3.cpp.o
>
> …
>
>
>
>   but may contain only sources that compile, header files, and other files
>
>   that would not affect linking of a normal library.
>
>
>
> CMake Error at lib/common/CMakeLists.txt:31 (add_library):
>
>   Only executables and non-OBJECT libraries may reference target objects.
>
>
>
> What’s the correct way to do this?
>
>
>
> Thanks.
>
> Simone
>
>
>
> 
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential information.  Any unauthorized review, use, disclosure
> or distribution is prohibited.  If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the
> original message.
> 
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.11.0-rc1 is now ready for testing

[Robert Maynard]

I am proud to announce the first CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes


Changes made since CMake 3.10 include the following.


New Features



Platforms
-

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
--

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands


* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
-

* A 

Re: [CMake] how to find CUDA libraries under new CUDA framework?

[Robert Maynard]

I would start by looking at the contents of
CMAKE_CUDA_IMPLICIT_LINK_LIBRARIES and
CMAKE_CUDA_HOST_IMPLICIT_LINK_LIBRARIES

On Sat, Dec 30, 2017 at 12:29 PM, Crni Gorac  wrote:
> The FindCUDA.cmake module would put list of CUDA libraries found into
> corresponding CMake variables.  Is there any variable with new
> "project(... LANGUAGES ... CUDA)" framework to do the same (I wasn't
> able to find it)?
>
> Basically, what I want to do is to have an option to install all
> dependencies of my project along with the project deliverables.  Thus
> libcudart_static.a is to be installed too. I can find it using
> find_library(), but am wondering is there a better way.
>
> Thanks.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

[Robert Maynard]

Hi,

I have a MR open for CMake that resolves this bug
(https://gitlab.kitware.com/cmake/cmake/merge_requests/1618)

On Thu, Sep 7, 2017 at 9:48 AM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> Okay I have opened an issue on CMake for handling multiple gencode with
> multiple code targets.
>
> On Wed, Sep 6, 2017 at 3:19 PM, Mueller-Roemer, Johannes Sebastian
> <johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:
>>
>> Yes
>>
>> ____
>> From: Robert Maynard [robert.mayn...@kitware.com]
>> Sent: Wednesday, September 06, 2017 6:58 PM
>> To: Mueller-Roemer, Johannes Sebastian
>> Cc: cmake@cmake.org
>> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
>> issues
>>
>> So it works when they are separate gen-code options, but fails when they
>> are combined. Is that correct?
>>
>>
>> On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian
>> <johannes.sebastian.mueller-roe...@igd.fraunhofer.de<mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
>> wrote:
>> The long form fills the Code Generation field with
>> compute_20,sm_20;compute_20,compute_20 (the default without gencode
>> parameters is compute_20,sm_20) and results in the following command line:
>>
>> D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU
>> Computing Toolkit\CUDA\v8.0\bin\nvcc.exe"
>> -gencode=arch=compute_20,code=\"sm_20,compute_20\"
>> -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env
>> --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio
>> 14.0\VC\bin\amd64"  -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing
>> Toolkit\CUDA\v8.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0
>> --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g
>> -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o
>> A.dir\Debug\a.cu.obj
>> "D:\jsroemer\projects\cuda-pdb-test\a\a.cu<http://a.cu>"
>>
>> Which is somewhat redundant
>>
>> MSVC turns compute_20,sm_20 into
>> -gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20
>> into -gencode=arch=compute_20,code=\"compute_20,compute_20\"
>>
>>
>> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>> Tel +49 6151 155-606<tel:+49%206151%20155606>  |  Fax +49 6151
>> 155-139<tel:+49%206151%20155139>
>>
>> johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de>
>> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de>
>>
>> From: Robert Maynard
>> [mailto:robert.mayn...@kitware.com<mailto:robert.mayn...@kitware.com>]
>> Sent: Wednesday, September 6, 2017 16:44
>>
>> To: Mueller-Roemer, Johannes Sebastian
>> <johannes.sebastian.mueller-roe...@igd.fraunhofer.de<mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
>> Cc: cmake@cmake.org<mailto:cmake@cmake.org>
>> Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags
>> issues
>>
>> Yes I was responding to comment 3.
>>
>> I am curious, does the longer form signature "-gencode
>> arch=compute_20,code=sm_20  -gencode arch=compute_20,code=compute_20" work
>> correctly? CMake has to parse the gencode flags and move them to special
>> msbuild entries, and I wonder if there is a bug when parsing multiple code
>> options.
>>
>> On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian
>> <johannes.sebastian.mueller-roe...@igd.fraunhofer.de<mailto:johannes.sebastian.mueller-roe...@igd.fraunhofer.de>>
>> wrote:
>> If the comment is wrt 3., the result is the same no matter if I use a
>> space or an equals sign, if I double escape the quotes (e.g., use the value
>> as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS
>> becomes compute_20,"sm_20,compute_20" instead of
>> compute_20,sm_20,compute_20, which is equally illegal and will cause the
>> same error message, also double escaping should not be necessary for a
>> subset of flags (Xcompiler works fine without it, even if the default values
>> are pointless).
>> If the comment is wrt 2., this is the line automatically generated by
>> CMake/VS when not passing in any gencode flags explicitly.
>>
&

Re: [CMake] "modern" CUDA handling and static libraries

[Robert Maynard]

> If a .cpp file is added to library, then it won't work.

If this is occurring it is a bug. Can you fill a bug report at:
https://gitlab.kitware.com/cmake/cmake

> CUDA_PROPAGATE_HOST_FLAGS

CUDA as a first class language propagates zero C++ flags as it is a
separate language, and we expect people to set CXX_FLAGS and
CUDA_FLAGS

On Wed, Dec 20, 2017 at 3:46 PM, Crni Gorac <cgo...@gmail.com> wrote:
> Thanks for your reply.
>
> That seems to work, but only if the library consist solely of .cu
> files.  If a .cpp file is added to library, then it won't work.  Is
> this a known limitation?
>
> On a related note: what is the equivalent of
> "set(CUDA_PROPAGATE_HOST_FLAGS OFF)" now?
>
> Regards.
>
> On Tue, Dec 19, 2017 at 11:47 PM, Robert Maynard
> <robert.mayn...@kitware.com> wrote:
>> Hi,
>>
>> The CUDA_RESOLVE_DEVICE_SYMBOLS property was added for this exact
>> situation. You can find it documented at
>> https://cmake.org/cmake/help/v3.10/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html
>>
>> Here is an example of it being used:
>> https://gitlab.kitware.com/cmake/cmake/commit/493671a5212c6548b2d7376c7065f5f76692a792#0eb128c2e695da6e4cedb9a408b108f117bd4fe3
>>
>> On Tue, Dec 19, 2017 at 3:14 PM, Crni Gorac <cgo...@gmail.com> wrote:
>>> Hello,
>>>
>>> My project is alike for what is described by following CMakeLists.txt
>>> for Cuda/Complex test case from CMake source distribution:
>>>
>>> #
>>> cmake_minimum_required(VERSION 3.8)
>>> project (CudaComplex CXX CUDA)
>>>
>>> string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_30,code=compute_30")
>>> set(CMAKE_CUDA_STANDARD 11)
>>> set(CMAKE_CXX_STANDARD 11)
>>> set(CMAKE_CUDA_STANDARD_REQUIRED TRUE)
>>> set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
>>>
>>> add_library(CudaLib STATIC dynamic.cu file1.cu file2.cu file3.cu mixed.cu)
>>> set_target_properties(CudaLib PROPERTIES CUDA_SEPARABLE_COMPILATION OFF)
>>> set_target_properties(CudaLib PROPERTIES POSITION_INDEPENDENT_CODE OFF)
>>>
>>> add_library(CppLib STATIC dynamic.cpp mixed.cpp)
>>>
>>> add_executable(CudaComplex main.cpp)
>>> target_link_libraries(CudaComplex PUBLIC CudaLib CppLib)
>>> #
>>>
>>> So basically I want to build all my .cu files into one static library,
>>> and all my .cpp files (except for main.cpp) into another static
>>> library. These two libraries are then linked into main.cpp above. This
>>> works fine, and make output is:
>>>
>>> #
>>> Scanning dependencies of target CppLib
>>> Scanning dependencies of target CudaLib
>>> [  8%] Building CXX object CMakeFiles/CppLib.dir/mixed.cpp.o
>>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file1.cu.o
>>> [ 25%] Building CUDA object CMakeFiles/CudaLib.dir/file2.cu.o
>>> [ 33%] Building CXX object CMakeFiles/CppLib.dir/dynamic.cpp.o
>>> [ 41%] Building CUDA object CMakeFiles/CudaLib.dir/dynamic.cu.o
>>> [ 50%] Building CUDA object CMakeFiles/CudaLib.dir/file3.cu.o
>>> [ 58%] Building CUDA object CMakeFiles/CudaLib.dir/mixed.cu.o
>>> [ 66%] Linking CXX static library libCppLib.a
>>> [ 66%] Built target CppLib
>>> [ 75%] Linking CUDA static library libCudaLib.a
>>> [ 75%] Built target CudaLib
>>> Scanning dependencies of target CudaComplex
>>> [ 83%] Building CXX object CMakeFiles/CudaComplex.dir/main.cpp.o
>>> [ 91%] Linking CUDA device code 
>>> CMakeFiles/CudaComplex.dir/cmake_device_link.o
>>> [100%] Linking CXX executable CudaComplex
>>> #
>>>
>>> However, in my case these static libraries are actually to be
>>> delivered to a client.  The problem is that the dynamic linking of
>>> CUDA code (this is this line "Linking CUDA device code
>>> CMakeFiles/CudaComplex.dir/cmake_device_link.o" in the make output
>>> above) would still have to get done on client side, i.e. they would
>>> have to install CUDA SDK and provide that this step is accomplished
>>> through their build system.  So my question is: is it possible to
>>> somehow generate static library with CUDA code, using this new
>>> "...LANGUAGE CUDA..." CMake functionality, but that CUDA linking is
>>> completed on my side (note that on client side no CUDA code will be
>>> added to project)?
>>>
>>> Thanks.
>>> --
>>>
>>> Powered by www.kitware

Re: [CMake] modularizing, specifying dependencies in a project

[Robert Maynard]

You will want to use add_subdirectory instead of include in the root
CMakeLists.txt and remove all include statements from ModA and ModB

It total the changes needed to get everything to work are:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index e611a37..b6968c1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,8 +1,9 @@
 cmake_minimum_required(VERSION 3.0)
 project(test_project)

-include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
-include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
+add_subdirectory(ModA)
+add_subdirectory(ModB)
+add_subdirectory(ModC)

 add_executable(main main.cpp)
 target_link_libraries(main
diff --git a/ModA/CMakeLists.txt b/ModA/CMakeLists.txt
index 87128d8..4931be6 100644
--- a/ModA/CMakeLists.txt
+++ b/ModA/CMakeLists.txt
@@ -1,5 +1,4 @@
-include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
-add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
+add_library(ModA a.cpp)
 target_link_libraries(ModA
PRIVATE
  ModC)
diff --git a/ModB/CMakeLists.txt b/ModB/CMakeLists.txt
index 3a31be9..7f83856 100644
--- a/ModB/CMakeLists.txt
+++ b/ModB/CMakeLists.txt
@@ -1,4 +1,3 @@
-include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)

 add_library(ModB b.cpp)
 target_link_libraries(ModB

On Wed, Jan 3, 2018 at 1:46 PM, Geogin Varghese  wrote:
> Hello,
>
> Recently came across these presentations on cmake:
>
> Using Modern CMake Patterns to Enforce a Good Modular Design
> (https://www.youtube.com/watch?v=bsXLMQ6WgIk)
> Effective CMake
> (https://www.youtube.com/watch?v=eC9-iRN2b04)
>
> They encourage using target_* command variants for scripting
> CMakeLists.txt.
>
> What would be the recommended way of writing build scripts for a
> repository structured as below. The application is compiled from three
> modules with a dependency among the modules as in the ascii diagram.
>
> Is it possible to distribute compile info, such that each submodule has
> a CMakeLists.txt that describes sources, include and link dependencies needed
> to compile that module.
>
> ---
> .
> ├── main.cpp
> ├── ModA
> ├── ModB
> ├── ModC
>
> Dependency relation:
> 
>++
> +->+main.cpp+<-+
> |  ++  |
> |  |
> |  |
> |  |
>   ++++
>   |ModA||ModB|
>   ++++
> ^  ^
> |  |
> |++|
> ++ModC++
>  ++
>
> ModA <- ModC: Module A
>  depends on Module C
> ---
>
> My naive effort to do this can be found here:
> https://github.com/vargheseg/test
>
> The problem I run into is with describing the dependency relation
> between ModA, ModB and ModC.
>
> Details:
> .
> ├── CMakeLists.txt
> ├── main.cpp
> ├── ModA
> │   ├── a.cpp
> │   └── CMakeLists.txt
> ├── ModB
> │   ├── b.cpp
> │   └── CMakeLists.txt
> ├── ModC
> │   ├── c.cpp
> │   └── CMakeLists.txt
>
> - CMakeLists.txt in the child directories describe compilation
>   information for that directory.
> - The top level directory includes the CMakeLists.txt from
>   subdirectories.
> - Cmake buildfile generation fails because the way I set things up; the
>   top level CMakeLists.txt ends up including ModC/CMakeLists.txt twice.
>
> ---
> CMakeLists.txt
> ---
>  cmake_minimum_required(VERSION 3.0)
>  project(test_project)
>
>  include(${CMAKE_CURRENT_LIST_DIR}/ModA/CMakeLists.txt)
>  include(${CMAKE_CURRENT_LIST_DIR}/ModB/CMakeLists.txt)
>
>  add_executable(main main.cpp)
>  target_link_libraries(main PRIVATE ModA ModB)
>
>
> ---
> ModA/CMakeLists.txt
> ---
>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>  add_library(ModA  $CMAKE_CURRENT_LIST_DIR}/a.cpp)
>  target_link_libraries(ModA PRIVATE ModC)
>
>
> ---
> ModB/CMakeLists.txt
> ---
>  include(${CMAKE_CURRENT_LIST_DIR}/../ModC/CMakeLists.txt)
>  add_library(ModB b.cpp)
>  target_link_libraries(ModB
>  PRIVATE
>  ModC)
>
> Is this way of structuring a project a supported use case?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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: 

Re: [CMake] Performance profiling for CMake scripts?

[Robert Maynard]

I am not aware of any built in functionality that can generate
performance numbers for a project.

Have you made sure that the performance/parsing policies are set to
NEW or your cmake_minimum_required is sufficiently high, those can
have a significant improvement on configuration time.

Polices ( both in CMake 3.1 )
 - CMP0054 'if parsing'
 - CMP0053 'simplified variable reference and escape parsing'

On Tue, Jun 19, 2018 at 2:12 PM Robert Dailey  wrote:
>
> So I noticed over the years my CMake scripts take longer and longer to
> configure/generate. Is there a mechanism to tell which parts of my
> CMake scripts are slowest? I'd like to know how to optimize my CMake
> scripts to reduce the time it takes to generate projects.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] VS 2017 + CUDA 9.0

[Robert Maynard]

When initially configuring a project you can specify which toolset you
would like to use. Starting in CMake 3.12 this now also supports
specifying which patch version. You can see what the syntax looks like
at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3
On Thu, Aug 2, 2018 at 4:12 PM Sophonet  wrote:
>
> Hi list,
>
> it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires 
> an old toolset to be installed for successful compilation (15.4, see 
> https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/).
>  The new VS 2017 toolset have an incompatible _MSC_VER variable, among other 
> things.
>
> The link above mentions to manually revert the toolset for a solution, but I 
> was wondering how CMake-based projects could be configured to automatically 
> pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake 
> documentation for toolsets is somehow sparse and only mentions toolsets with 
> name „v141“, which I think would apply for both. Any hints to find out (i) 
> what toolsets are actually available for a specific compiler or (ii) forcing 
> toolset 14.12 as mentioned above - without manual editing of the vcproj 
> project files?
>
> Thanks,
>
> Sophonet
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] AUTOUIC generated headers not found by lib that uses lib with headers

[Robert Maynard]

You need to defer the evaluation of the include directory to generate
time, which will know what exactly build type is needed. This is done
by using `$` instead of `${CMAKE_BUILD_TYPE`.

Something like the following should work:

set(directory 
"${CMAKE_CURRENT_BINARY_DIR}/ComponentsLib_autogen/include_$")
target_include_directories(ComponentsLib INTERFACE ${directory})
On Mon, Jul 30, 2018 at 1:48 PM Jim Carroll  wrote:
>
> I have a project that I'm updating from Cmake 3.5 to 3.12.
>
> In the project, I have UI libraries that use other libraries, both of which 
> use Qt 5.6.
> The lowest-level library uses AUTOUIC and I see the headers are generated in 
> the new lib_autogen/include_BUILD_CONFIG directory.
>
> When my higher level library tries to use the lower level library, I get the 
> error that it can't find the auto-generated headers. It only seems to have 
> trouble finding about six of two dozen ui_***.h files.
>
> How can I get my lower level libraries to include the generated header files 
> so they're available to the higher level library that's using it?
>
> I'm using
> cmake 3.12
> Qt 5.6
> Visual Studio 2015
>
> I tried creating a work-around where in the CMakeLists.txt of my lowest level 
> directory I add
>
> # CMake 10+ has a bug where automoc header files aren't found
> SET(COMPONENTS_UIC_HDRS_DIR 
> "${CMAKE_CURRENT_BINARY_DIR}/ComponentsLib_autogen/include_${CMAKE_BUILD_TYPE}")
> message("** COMPONENTS AUTOUIC autogen dir: ${COMPONENTS_UIC_HDRS_DIR}")
> target_include_directories(ComponentsLib INTERFACE ${COMPONENTS_UIC_HDRS_DIR})
>
> but of course the CMAKE_BUILD_TYPE isn't available to CMake at this time. I'd 
> have to move the headers into a place common to the various (Debug/Release) 
> configurations or something.
>
> Thanks!
> -Jim
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] order of includes seems wrong (or please help me understand)

[Robert Maynard]

The BEFORE keyword places the includes before any other paths such as
ones from other target_include_directories statements or from
transitive propagation from targets you linked too.

As to why `CMAKE_PREFIX_PATH` is being added, I expect that some find
call is bring it in as an include directory.
On Mon, Jul 30, 2018 at 5:43 PM Mario Emmenlauer  wrote:
>
>
> Should I report this as a bug or am I just doing something wrong?
> Help would be greatly appreciated!
>
> All the best,
>
> Mario
>
>
> On 26.07.2018 11:58, Mario Emmenlauer wrote:
> >
> > Dear CMake users and developers,
> >
> > I've just discovered a build problem that comes from a wrong order of
> > includes. I would know the correct order, but I am unable to instruct
> > CMake to use the order I need.
> >
> > Here is a toy example that I tested with cmake 3.12.0:
> >
> >
> > 
> > cmake_minimum_required(VERSION 3.8)
> > project(MyLib VERSION 1.0.0)
> > find_package(XXX REQUIRED)
> > find_package(YYY REQUIRED)
> > add_library(${PROJECT_NAME} include/MyLib.hh src/MyLib.cc)
> > target_include_directories(${PROJECT_NAME}
> > PRIVATE
> > ${CMAKE_CURRENT_SOURCE_DIR}/src
> > ${CMAKE_CURRENT_BINARY_DIR}
> > PUBLIC
> > $
> > $
> > ${XXX_INCLUDE_DIRS} ${YYY_INCLUDE_DIRS})
> > target_link_libraries(MyLib PUBLIC ${XXX_LIBRARIES} ${YYY_LIBRARIES})
> > # here come more commands for build flags etc.
> >
> > enable_testing()
> > add_executable(MyTest test/src/MyTest.cc test/src/MyTest.hh)
> > target_include_directories(MyTest PRIVATE
> > ${CMAKE_CURRENT_SOURCE_DIR}/include
> > ${CMAKE_CURRENT_SOURCE_DIR}/test/src
> > ${CMAKE_CURRENT_SOURCE_DIR}/src
> > ${CMAKE_CURRENT_BINARY_DIR}
> > ${GTEST_INCLUDE_DIRS})
> > target_link_libraries(MyTest PRIVATE MyLib ${GTEST_MAIN_LIBRARIES})
> > # here come more commands for build flags etc.
> > 
> >
> >
> > I configure cmake with -DCMAKE_PREFIX_PATH=${MY_PREFIX_PATH}. When
> > I build the project, the order of includes for MyLib is fine. But
> > for MyTest, the following are the first two includes:
> >-IMyTest_autogen/include
> >-I${MY_PREFIX_PATH}/include
> >
> > I think the second include should come much later, only *after*
> > ${CMAKE_CURRENT_SOURCE_DIR}/include, but it comes before. Therefore,
> > if older headers exists in ${MY_PREFIX_PATH}/include, they will be
> > used instead of ${CMAKE_CURRENT_SOURCE_DIR}/include!
> >
> > I found that I can fix the problem by adding 'BEFORE' to all
> > target_include_directories(). However I'm puzzled why this helps.
> > Before anything I call target_include_directories(), and before other
> > includes I have ${CMAKE_CURRENT_SOURCE_DIR}/src,
> > ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}/include.
> > So what does 'BEFORE' mean in this case? Aren't these the first
> > includes any ways?
> >
> > Thanks for any help, and Cheers,
> >
> > Mario Emmenlauer
>
>
>
> Viele Gruesse,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake for CUDA with MPICC still using gcc to link?

[Robert Maynard]

The CUDA_HOST_COMPILER must be specified as a -D option on the first
invocation of cmake as it is used during the compiler detection
process.

The _LINKER_PREFERENCE is a numeric value that determines which
language will be selected for linking when a library/executable has
source files from multiple languages.
On Tue, Jul 31, 2018 at 3:31 PM Quang Ha  wrote:
>
> Thanks Robert - specific at the cmake -D [...] command seemsd to work. Is it 
> possible to set this inside a CMakeLists.txt? I have tried:
>
> set(CUDA_HOST_COMPILER ${CMAKE_CXX_COMPILER})
> set(CUDA_LINKER_PREFERENCE ${CMAKE_CXX_COMPILER})
>
> but it snaps back to gcc still.
>
> Thanks,
> QT
>
> On Tue, 31 Jul 2018 at 13:12, Robert Maynard  
> wrote:
>>
>> It is snapping back to g++ as that was the linker that nvcc uses when
>> it builds an executable. CMake detects this as part of the compiler
>> detection process.
>>
>> I haven't verified that this will work but you can try specifying the
>> LINKER_LANGUAGE(https://cmake.org/cmake/help/v3.12/prop_tgt/LINKER_LANGUAGE.html)
>> of the executable to be 'CXX'. You might also explore specifying
>> 'CMAKE_CUDA_HOST_COMPILER' as part of your initial cmake configuration
>> options to be the same as your c++ compiler ( you will need a clean
>> build directory for this to work).
>> On Tue, Jul 31, 2018 at 1:43 PM Quang Ha  wrote:
>> >
>> > Hi all,
>> >
>> > Currently using cmake/3.11.1, I want to try and compile MPI/CUDA 
>> > application with cmake. I kept running into problems of 'undefined 
>> > MPI_Init', so I take a look at `make VERBOSE=1`. The output looks 
>> > something like this
>> >
>> > ===
>> > /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script 
>> > CMakeFiles/tangram.dir/link.txt --verbose=1
>> > /projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc -fPIC -fopenmp -O3 
>> > -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so 
>> > CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
>> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
>> > [ 40%] Built target tangram
>> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make 
>> > app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
>> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
>> > cd /home/qth20/develop/tangram/build && 
>> > /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix 
>> > Makefiles" /home/qth20/develop/tangram 
>> > /home/qth20/develop/tangram/app/vfgen-cuda 
>> > /home/qth20/develop/tangram/build 
>> > /home/qth20/develop/tangram/build/app/vfgen-cud$
>> >  
>> > /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake
>> >  --color=
>> > make[2]: Leaving directory `/home/qth20/develop/tangram/build'
>> > make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make 
>> > app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
>> > make[2]: Entering directory `/home/qth20/develop/tangram/build'
>> > [ 60%] Building CUDA object 
>> > app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
>> > cd /home/qth20/develop/tangram/build/app/vfgen-cuda && 
>> > /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__ 
>> > __device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX 
>> > -DOMPI_SKIP_MPICXX -DTHRUST 
>> > -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -DTHRUST$
>> > HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram 
>> > -I/home/qth20/develop/tangram/build 
>> > -I/home/qth20/develop/tangram/cinch/logging 
>> > -I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include 
>> > -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
>> > -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include
>> >  -I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include 
>> > -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
>> >  -I/home/qth20/installed$
>> > jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++ 
>> > -I/usr/include/lapacke 
>> > -I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include 
>> > -I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr 
>> > --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
>> > qth20/develop/tangram/app/vfgen-cuda/vfgen-cud

Re: [CMake] CMake for CUDA with MPICC still using gcc to link?

[Robert Maynard]

It is snapping back to g++ as that was the linker that nvcc uses when
it builds an executable. CMake detects this as part of the compiler
detection process.

I haven't verified that this will work but you can try specifying the
LINKER_LANGUAGE(https://cmake.org/cmake/help/v3.12/prop_tgt/LINKER_LANGUAGE.html)
of the executable to be 'CXX'. You might also explore specifying
'CMAKE_CUDA_HOST_COMPILER' as part of your initial cmake configuration
options to be the same as your c++ compiler ( you will need a clean
build directory for this to work).
On Tue, Jul 31, 2018 at 1:43 PM Quang Ha  wrote:
>
> Hi all,
>
> Currently using cmake/3.11.1, I want to try and compile MPI/CUDA application 
> with cmake. I kept running into problems of 'undefined MPI_Init', so I take a 
> look at `make VERBOSE=1`. The output looks something like this
>
> ===
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script 
> CMakeFiles/tangram.dir/link.txt --verbose=1
> /projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/bin/mpicc -fPIC -fopenmp -O3 
> -DNDEBUG  -shared -Wl,-soname,libtangram.so -o libtangram.so 
> CMakeFiles/tangram.dir/tangram/intersect/r3d.c.o
> make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> [ 40%] Built target tangram
> make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make 
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/depend
> make[2]: Entering directory `/home/qth20/develop/tangram/build'
> cd /home/qth20/develop/tangram/build && 
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_depends "Unix 
> Makefiles" /home/qth20/develop/tangram 
> /home/qth20/develop/tangram/app/vfgen-cuda /home/qth20/develop/tangram/build 
> /home/qth20/develop/tangram/build/app/vfgen-cud$
>  
> /home/qth20/develop/tangram/build/app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/DependInfo.cmake
>  --color=
> make[2]: Leaving directory `/home/qth20/develop/tangram/build'
> make -f app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build.make 
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/build
> make[2]: Entering directory `/home/qth20/develop/tangram/build'
> [ 60%] Building CUDA object 
> app/vfgen-cuda/CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && 
> /projects/opt/centos7/cuda/9.0/bin/nvcc  -DCUDA_CALLABLE="\"__host__ 
> __device__\"" -DENABLE_MPI -DHAVE_LAPACKE -DMPICH_SKIP_MPICXX 
> -DOMPI_SKIP_MPICXX -DTHRUST -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA 
> -DTHRUST$
> HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP -I/home/qth20/develop/tangram 
> -I/home/qth20/develop/tangram/build 
> -I/home/qth20/develop/tangram/cinch/logging 
> -I/home/qth20/installed/jali-gcc_6.4.0-openmpi-2.1.2/include 
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/include
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/include
>  -I/projects/opt/centos7/openmpi/2.1.2-gcc_6.4.0/include 
> -I/home/qth20/installed/jali-tpls-gcc_6.4.0-openmpi-2.1.2/trilinos-12-10-1/lib/cmake/Zoltan/../../../include
>  -I/home/qth20/installed$
> jali-tpls-gcc_6.4.0-openmpi-2.1.2/include/UnitTest++ -I/usr/include/lapacke 
> -I/home/qth20/installed/xmof2d-gcc_6.4.0-openmpi_2.1.2/include 
> -I/projects/opt/centos7/cuda/9.0/include  --expt-relaxed-constexpr 
> --std=c++11 -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG   -x cu -c /home$
> qth20/develop/tangram/app/vfgen-cuda/vfgen-cuda.cu -o 
> CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1708): 
> warning: variable "nnodes" was declared but never referenced
>
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(1993): 
> warning: variable "ncells" was declared but never referenced
>
> /home/qth20/develop/tangram/tangram/wrappers/mesh/AuxMeshTopology.h(2070): 
> warning: variable "ibndry" was declared but never referenced
>
> [ 80%] Linking CUDA device code CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && 
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script 
> CMakeFiles/vfgen-cuda.dir/dlink.txt --verbose=1
> /projects/opt/centos7/cuda/9.0/bin/nvcc  --expt-relaxed-constexpr --std=c++11 
> -Xcompiler -fPIC -lmpi  -O3 -DNDEBUG  -Xcompiler=-fPIC 
> -Wno-deprecated-gpu-targets -shared -dlink 
> CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o -o 
> CMakeFiles/vfgen-cuda.dir/cmake_device_link.o
> [100%] Linking CUDA executable vfgen-cuda
> cd /home/qth20/develop/tangram/build/app/vfgen-cuda && 
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E cmake_link_script 
> CMakeFiles/vfgen-cuda.dir/link.txt --verbose=1
> /projects/opt/centos7/gcc/6.4.0/bin/g++   
> CMakeFiles/vfgen-cuda.dir/vfgen-cuda.cu.o 
> CMakeFiles/vfgen-cuda.dir/cmake_device_link.o -o vfgen-cuda 
> /projects/opt/centos7/cuda/9.0/lib64/libcudart_static.a -ldl 
> /usr/lib64/librt.so  -L"/projects/opt/centos7/cuda/9.0/lib64/stubs"
>  -L"/projects/opt/centos7/cuda/9.0/lib64" 

Re: [CMake] LD_LIBRARY_PATH not used by the linker

[Robert Maynard]

When you dumb out the contents of VTK_LIBRARIES do you see
';/home2/softmassot/eb/Compiler/GCCcore/7.2.0/Python/2.7.14-bare/lib/libpython2.7.so'.

In general CMake will only stop using the absolute path of a library
when the library resides in an implicit directory provided by the
compiler. On Thu, Aug 2, 2018 at 4:13 PM Ruben Di Battista
 wrote:
>
> Thanks for your answer,
>
> The thing is that, since the Python dependency comes from VTK, I checked in 
> the VTK install directory all the CMake configuration files (In particulare 
> the UseVTK.cmake) file to see if they keep the Python path somewhere.
>
> And it happens that yes, they do.
> If I run: `grep -e 'python2.7' -r `, I 
> actually get that in the file `VTKTargets.cmake`and in the 
> `Modules/vtkPython.cmake` they actually keep the path of the python used to 
> compile VTK.
>
> For example in VTKTargets.cmake, you find:
>
> set_target_properties(vtkWrappingPythonCore PROPERTIES
>   INTERFACE_LINK_LIBRARIES 
> "vtkCommonCore;/home2/softmassot/eb/Compiler/GCCcore/7.2.0/Python/2.7.14-bare/lib/libpython2.7.so;vtksys"
> )
>
> So when I link my test target to ${VTK_LIBRARIES}, shouldn't it also be able 
> to retrieve the right python library from the target properties?
>
>
> On Thu, Aug 2, 2018 at 9:56 PM Roger Leigh  wrote:
>>
>> It's the quick and easy way to do it.
>>
>> However, I'd suggest looking at getting CMake to use the proper path
>> without it.  Can you use any module-specific variables like
>> PYTHON_LIBRARY to override the search.  Or even just add to
>> CMAKE_PREFIX_PATH.  (Does VTK support imported targets?)
>>
>> Regards,
>> Roger
>>
>> On 02/08/18 20:43, Ruben Di Battista wrote:
>> > Hi Roger,
>> > so I explicitly passing the LDFLAGS is the way to go?
>> >
>> > On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh > > > wrote:
>> >
>> > On 02/08/18 20:03, Ruben Di Battista wrote:
>> >
>> >  > I'm running cmake on a system where I have module-loaded software
>> > such
>> >  > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm
>> > using
>> >  > Lmod) function.
>> >
>> > LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used
>> > when linking at *build* time, with ld.
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
>   _
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `'
> https://rdb.is
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ctest to output files

[Robert Maynard]

I would look at use the FIXTURES features to define the file as a
shared resource. Here is a good article on how to use this feature:

https://crascit.com/2016/10/18/test-fixtures-with-cmake-ctest/
On Wed, Aug 1, 2018 at 12:32 AM Quang Ha  wrote:
>
> Hi all,
>
> Is there a way to let ctest create an output file after a certain test? Say I 
> want to run test 1 (name "run_simulation"), which is a simulation and should 
> produce an output file containing numerical results. I then want to compare 
> it against analytical results in test 2 (name "compare_results")?
>
> Thanks,
> QT
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] order of includes seems wrong (or please help me understand)

[Robert Maynard]

While the find modules that CMake provide don't use
include_directories some externally written find module you are using
could.

You really need to provide a standalone reproduction of the problem,
as currently people can only speculate on what is occurring.
On Thu, Aug 2, 2018 at 7:58 AM Mario Emmenlauer  wrote:
>
>
> Dear Robert,
>
> On 31.07.2018 15:04, Robert Maynard wrote:
> > The BEFORE keyword places the includes before any other paths such as
> > ones from other target_include_directories statements or from
> > transitive propagation from targets you linked too.
> >
> > As to why `CMAKE_PREFIX_PATH` is being added, I expect that some find
> > call is bring it in as an include directory.
> > On Mon, Jul 30, 2018 at 5:43 PM Mario Emmenlauer  
> > wrote:
>
> I would like to understand why `CMAKE_PREFIX_PATH` is in second position
> of includes. I add ${CMAKE_CURRENT_SOURCE_DIR}/include before. Are you
> saying that find_package() is modifying the includes directly, like by
> calling include_directories()? That would be pretty bad!
>
> I am rather under the assumption that target_link_libraries() is changing
> the order of includes.
>
> All the best,
>
>Mario
>
>
>
> >>
> >> Should I report this as a bug or am I just doing something wrong?
> >> Help would be greatly appreciated!
> >>
> >> All the best,
> >>
> >> Mario
> >>
> >>
> >> On 26.07.2018 11:58, Mario Emmenlauer wrote:
> >>>
> >>> Dear CMake users and developers,
> >>>
> >>> I've just discovered a build problem that comes from a wrong order of
> >>> includes. I would know the correct order, but I am unable to instruct
> >>> CMake to use the order I need.
> >>>
> >>> Here is a toy example that I tested with cmake 3.12.0:
> >>>
> >>>
> >>> 
> >>> cmake_minimum_required(VERSION 3.8)
> >>> project(MyLib VERSION 1.0.0)
> >>> find_package(XXX REQUIRED)
> >>> find_package(YYY REQUIRED)
> >>> add_library(${PROJECT_NAME} include/MyLib.hh src/MyLib.cc)
> >>> target_include_directories(${PROJECT_NAME}
> >>> PRIVATE
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>> ${CMAKE_CURRENT_BINARY_DIR}
> >>> PUBLIC
> >>> $
> >>> $
> >>> ${XXX_INCLUDE_DIRS} ${YYY_INCLUDE_DIRS})
> >>> target_link_libraries(MyLib PUBLIC ${XXX_LIBRARIES} ${YYY_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>>
> >>> enable_testing()
> >>> add_executable(MyTest test/src/MyTest.cc test/src/MyTest.hh)
> >>> target_include_directories(MyTest PRIVATE
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/include
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/test/src
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/src
> >>> ${CMAKE_CURRENT_BINARY_DIR}
> >>> ${GTEST_INCLUDE_DIRS})
> >>> target_link_libraries(MyTest PRIVATE MyLib ${GTEST_MAIN_LIBRARIES})
> >>> # here come more commands for build flags etc.
> >>> 
> >>>
> >>>
> >>> I configure cmake with -DCMAKE_PREFIX_PATH=${MY_PREFIX_PATH}. When
> >>> I build the project, the order of includes for MyLib is fine. But
> >>> for MyTest, the following are the first two includes:
> >>>-IMyTest_autogen/include
> >>>-I${MY_PREFIX_PATH}/include
> >>>
> >>> I think the second include should come much later, only *after*
> >>> ${CMAKE_CURRENT_SOURCE_DIR}/include, but it comes before. Therefore,
> >>> if older headers exists in ${MY_PREFIX_PATH}/include, they will be
> >>> used instead of ${CMAKE_CURRENT_SOURCE_DIR}/include!
> >>>
> >>> I found that I can fix the problem by adding 'BEFORE' to all
> >>> target_include_directories(). However I'm puzzled why this helps.
> >>> Before anything I call target_include_directories(), and before other
> >>> includes I have ${CMAKE_CURRENT_SOURCE_DIR}/src,
> >>> ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}/include.
> >>> So what does 'BEFORE' mean in this case? Aren't these the first
> >>> includes any ways?
> >>>
> >>> Thanks for any help, and Cheers,
> >>>
> >>> Mario Emmenlauer
> >>
> >>
> >>
> >> Viele Gruesse,
> >>
> >> Mario Emmenlauer
> 

Re: [CMake] VS 2017 + CUDA 9.0

[Robert Maynard]

The CUDA_ADD_LIBRARY infrastructure is deprecated and it is
understandable that it isn't aware of the toolsets since it is based
on custom commands.

I recommend using the new CUDA first class language support. You can
find an intro blog post on using this at:
https://devblogs.nvidia.com/building-cuda-applications-cmake/
On Wed, Aug 8, 2018 at 3:58 PM Sophonet  wrote:
>
> Hi Robert,
>
> thanks for the hint - indeed, it somewhat solved the problems I have 
> mentioned. However, the CMake backend for CUDA (one of the preprocessing 
> steps in CUDA_ADD_LIBRARY for example) calls nvcc -M (do get dependencies), 
> and this command first tries to load vcvars.bat without any command line 
> options. Therefore, nvcc -M still sees the default toolkit and not the one 
> which I have specified with CMAKE_GENERATOR_TOOLSET=„version=14.11“.
>
> The only solution up to now is to run the vcvars.bat script from VS 2017 
> before doing any cmake operations with the option "-vcvars_ver=14.11“, such 
> that the INCLUDE_PATH variables etc are already set to the right value before 
> nvcc tries to set them anew (with the wrong value).
>
> Any hint how this can be added to the CUDA functionality in CMake? I guess 
> others might stumble across this problem as well.
>
> Thanks,
>
> Sophonet
>
> Am 02.08.2018 um 22:50 schrieb Robert Maynard :
>
> When initially configuring a project you can specify which toolset you
> would like to use. Starting in CMake 3.12 this now also supports
> specifying which patch version. You can see what the syntax looks like
> at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3
> On Thu, Aug 2, 2018 at 4:12 PM Sophonet  wrote:
>
>
> Hi list,
>
> it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires 
> an old toolset to be installed for successful compilation (15.4, see 
> https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/).
>  The new VS 2017 toolset have an incompatible _MSC_VER variable, among other 
> things.
>
> The link above mentions to manually revert the toolset for a solution, but I 
> was wondering how CMake-based projects could be configured to automatically 
> pick the 15.4 toolset (which has version 14.11 instead of 14.12). The CMake 
> documentation for toolsets is somehow sparse and only mentions toolsets with 
> name „v141“, which I think would apply for both. Any hints to find out (i) 
> what toolsets are actually available for a specific compiler or (ii) forcing 
> toolset 14.12 as mentioned above - without manual editing of the vcproj 
> project files?
>
> Thanks,
>
>Sophonet
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.1 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.12.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.12.1 since 3.12.0:

Brad King (8):
  CSharp: Set CMAKE_CSharp_COMPILER_LOADED variable when language is enabled
  UseSWIG: Use CSharp language only if it is enabled
  Help: Add explicit _ROOT variable documentation
  Tests: Add case showing CMP0048 warning on injected project command
  project: Do not issue CMP0048 warnings on injected call
  CPack: Restore support for 0-valued version components
  FindCUDA/select_compute_arch: Restore two-component CUDA_VERSION
  CMake 3.12.1

Craig Scott (1):
  GoogleTest: Ensure policy settings allow use of IN_LIST

Dima Panov (1):
  FindTCL: Add support for version 8.7

Marc Chevrier (2):
  FindPython*: fix erroneous behavior on multiple 'find_package' calls
  UseSWIG: restore legacy behavior for SWIG_MODULE__EXTRA_FLAGS
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Install interface

[Robert Maynard]

Installing interface libraries has no effect without the 'EXPORT'
keyword as they have no artifacts, you will need to install the actual
archives to get any artifacts.

To generate a CMake file containing the correct import targets for
consumers of your project you should like at the 'EXPORT' keyword for
the install command (
https://cmake.org/cmake/help/latest/command/install.html#export )
On Sat, Aug 4, 2018 at 7:13 AM Quaquaraquà  wrote:
>
> Good morning,
> given the following configuration:
>
> /CMakeLists.txt
> /include/
> /lib1/CMakeLists.txt
> /lib2/CMakeLists.txt
> ...
>
> where each /lib.*/CMakeLists.txt creates its own archive:
>
> add_library(lib.* EXCLUDE_FROM_ALL
> foo.cpp
> bar.cpp
> )
> target_link_libraries(lib1 PUBLIC interface)
>
> and the final /CMakeLists.txt should wrap all libraries together::
>
> add_library(interface INTERFACE)
> target_include_directories(interface INTERFACE include/)
> add_subdirectory(lib1 lib2 ...)
> add_library(libcommon INTERFACE)
> target_link_libraries(libcommon INTERFACE lib1 lib2 ...)
>
> I wonder how to create an install target for the final library `libcommon' ?
> This snippet doesn't seem effective with INTERFACE targets:
> install(TARGETS libcommon
> RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
> ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
> LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> )
>
> Thanks,
> Quack
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

[Robert Maynard]

> cannot find CUDA likely as CUDA was not installed after 2017

The CUDA language support requires the CUDA MSBUILD extensions, which
will require you to run the CUDA installer again ( it only installs
the msbuild extensions for versions that are currently installed ).

>  I would like it to load 2013 after being told to generate Visual Studio 2013 
> project files.

 As Hendrik stated CMake defers to the windows shell/explorer for
opening solution files.
On Tue, Aug 14, 2018 at 7:27 PM Brian Davis  wrote:
>
>
> It also cannot find CUDA likely as CUDA was not installed after 2017.  I 
> would like it to load 2013 after being told to generate Visual Studio 2013 
> project files.  Is this difficult to ask fo Kitware?  I am sure there are 
> certainly some shenanigans like path or VS2017 hooking calls to 2013 tools or 
> the like all of which I am sure make sens to a cubite in the bowels of the MS 
> machine.  VS loaded 2017 and vs 2013  proj files then promptly had problems 
> searching files, compiling stale targets and the like.  So while VS2017 make 
> "hook" 2013 tools it certainly can't do any thing useful with them IME.  Is 
> there a Meta buld tool (goop generator) that will build goop for a target 
> goop reader then call said target goop reader (of correct specified version) 
> to read goop and compile my code?  sigh.
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

[Robert Maynard]

tification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Hmm that ain't never going to work.  I installed 9.0 after VS2017 install
> however.
>
>
> Configure -> VS 2017 -> cuda=9.0 in (optional toolset to use (argument to
> -T)) ->Generate -> Open Project
>
> Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
>
> The CXX compiler identification is MSVC 19.14.26433.0
>
> The CUDA compiler identification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Ditto for that attempt
>
> Configure -> VS 2017 -> leave blank in desperate hope CMake will figure it
> out  in (optional toolset to use (argument to -T)) ->Generate -> Open
> Project
>
>
> Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
>
> The CXX compiler identification is MSVC 19.14.26433.0
>
> The CUDA compiler identification is unknown
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
>
> Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
> Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
> works
>
> Detecting CXX compiler ABI info
>
> Detecting CXX compiler ABI info - done
>
> Detecting CXX compile features
>
> Detecting CXX compile features - done
>
> CMake Error at CMakeLists.txt:14 (PROJECT):
> No CMAKE_CUDA_COMPILER could be found.
>
> Ditto for that attempt
>
> Aces! This sure is awesome.
>
>
>
>
> On Wed, Aug 15, 2018 at 10:45 AM, Brian Davis  wrote:
>
>> Yes I know all about the bit about having to reinstall CUDA (been using
>> it since the 2.0 days) for 2017 (using VS since 2005) if only I could
>> get CMake to call VS2013... ya know the version that already has cuda 8.0
>> installed and configured and the extensions from C:\Program Files\NVIDIA
>> GPU Computing
>> Toolkit\CUDA\v8.0\extras\visual_studio_integration\MSBuildExtensions that
>> get installed
>>
>> Can CMake defer to what the user ultimately wants? .. say the correct
>> version of VS.  I mean that is what I thought I specified.
>>
>> I had thought when I upgraded to 3.8/3.9 or whatever at the time that ...
>> Oh great they now have an open project button... .maybe that will allow me
>> to not have to generate .bat scripts to load VS (mind you my .bat script
>> generation in CMake could actually tell me which correct version to load so
>> these kinds of things are possible) with the env vars I set and set them in
>> CMake and have CMake load VS (again correct version) with said env.  It
>> worked like a charm... well for a while anyway as it does with anything in
>> the tech world.  I certainly feel like I have upgraded.
>>
>>
>> On Wed, Aug 15, 2018 at 9:48 AM, Robert Maynard <
>> robert.mayn...@kitware.com> wrote:
>>
>>> > cannot find CUDA likely as CUDA was not installed after 2017
>>>
>>> The CUDA language support requires the CUDA MSBUILD extensions, which
>>> will require you to run the CUDA installer again ( it only installs
>>> the msbuild extensions for versions that are currently installed ).
>>>
>>> >  I would like it to load 2013 after being told to generate Visual
>>> Studio 2013 project files.
>>>
>>>  As Hendrik stated CMake defers to the windows shell/explorer for
>>> opening solution files.
>>> On Tue, Aug 14, 2018 at 7:27 PM Brian Davis  wrote:
>>> >
>>> >
>>> > 

Re: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.

[Robert Maynard]

> Can't that be set by passing the toolset with a -T

That is what I was trying to say with my last sentence. You will need
to use CMake 3.12 to have support for specifying the minor toolset
version though.
On Thu, Aug 16, 2018 at 3:31 PM J Decker  wrote:
>
>
> On Thu, Aug 16, 2018 at 9:18 AM Brian Davis  wrote:
>>
>>
>>
>> On Wed, Aug 15, 2018 at 11:58 AM, Robert Maynard 
>>  wrote:
>>>
>>> The MSVC / CUDA support recently has been very challenging to keep track 
>>> of. In general CUDA will only support a single patch release of MSVC, and 
>>> given how MSVC 2017 doesn't easily allow rollbacks and has a pretty 
>>> aggressive update policy ( compared to older MSVC versions ) causes lots of 
>>> pain. This in general has been a community wide MSVC+CUDA issue.
>>>
>>> CUDA 8 has zero support for VS2017 ( 
>>> https://docs.nvidia.com/cuda/archive/8.0/cuda-installation-guide-microsoft-windows/index.html
>>>  )
>>> CUDA 9.0 and 9.1 only supports VS 2017 15.0 
>>> (https://docs.nvidia.com/cuda/archive/9.0/cuda-installation-guide-microsoft-windows/index.html,
>>>  
>>> https://docs.nvidia.com/cuda/archive/9.1/cuda-installation-guide-microsoft-windows/index.html)
>>> CUDA 9.2 only supports VS 2017 15.0 and 15.6
>>>
>>> When using MSVC 2017 and CUDA you will need to specify an explicit host 
>>> side compiler with -T version=15.## including the minor version ( 
>>> https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 ).
>>
>>
>>
> Can't that be set by passing the toolset with a -T ? like -T "v120_xp"or 
> -T "v120"
>
> This is an article about side-by-side toolsets 
> https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/
>   but it looks like it only goes back to 2015...
>
> (and sorry to ramble a bit)
> Slightly off topic; but I ran into a feature of the new optimizer that 
> shuffles commands I had a critical section lock that it ended up clearing 
> the locking bit, before releasing the other value; can defiantly see lots of 
> code breaking from that; firefox wants to only build with 15.6 but community 
> is only 15.5 or 15.8 preview...  (I fixed the codea dding 'volatile , and 
> referencing the other value with a computation that resulted with 0 instead.)
>
> Sometimes code is in a certain order for specific reasons :) Sometims, it can 
> be shuffled    (a=1;b=2;) ~~ (b=2;a=1) (same result different order)
>
>
>
>>
>> sigh... of course (though be careful with the term does not and cannot and 
>> zero support - I am a thinkin I could get CMake to support CUDA 8 in VS2017 
>> - if I realy wanted to - I mean it's not realy VS/MSVC doing the compiling 
>> is it?-rhetorical).  This is making the case for what I had to do in the 2.8 
>> days (well also again when NVIDIA could not decide on where to put their 
>> stuff in the file system and CMake was always one version or so behind) and 
>> roll my own CMake cuda support... yes this happened... and it could again.  
>> Time to look back into my old svn tree.  sweet... kickin it with svn again 
>> the good old days.
>>
>>
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Re: [CMake] cmake fails on first run but succeeds when run again after make

[Robert Maynard]

The error sounds like the file needs to be marked as GENERATED (
https://cmake.org/cmake/help/latest/prop_sf/GENERATED.html ) but I
would have thought qt5_add_resources would do that for you.

You might look at using CMake built in rc support (
https://cmake.org/cmake/help/latest/prop_tgt/AUTORCC.html )On Sun, Aug
5, 2018 at 4:54 AM Damir Porobic  wrote:
>
> Hi folks,
>
>
> I'm trying to troubleshoot a build problem where, when I first time run 
> "cmake .." it fails to find a resource file, when I run "make" it builds the 
> resource files but fails later on, now when I try to run "cmake .." again it 
> succeeds. After this point everything runs fine and it happens when building 
> for the first time.
>
> Any idea what I'm doing wrong?
>
>
> Here are the CMakeList files https://pastebin.com/pyhVTJUr and the output 
> that I get https://pastebin.com/4wGjR3Lx
>
>
> Thanks in advance!
>
>
> Damir
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Copy file from Source to Build dir based on CMAKE_CFG_INTDIR

[Robert Maynard]

You can use `file(GENERATE` and the `$` generator expression.

Here is an example:
https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Tests/CudaOnly/ExportPTX/CMakeLists.txt#L13
On Thu, Aug 23, 2018 at 1:47 PM Michael Jackson
 wrote:
>
> I would like to copy some files from my source dir into my binary RUNTIME_DIR 
> based on the current configuration being compiled. For generators like 
> “makefiles” and “ninja” this is easy and straight forward. I am having an 
> issue getting my head wrapped around how to use CMAKE_CFG_INTDIR properly.
>
>
>
> I know I can’t do this a cmake time so I tried the following:
>
>
>
> During CMake time write out another CMake file:
>
>
>
>   file(APPEND "${PYSIMPL_SCRIPT_COPY_RULE}"
>
> "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different
>
>   \"${SIMPLPyBind11_SOURCE_DIR}/../Testing/${script}\"
>
>   
> \"${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/\${CMAKE_CFG_INTDIR}/python/site-packages/${script}\")\n"
>
>   )
>
>
>
> Which creates entries like this in the written .cmake file:
>
>
>
> execute_process(COMMAND 
> C:/DREAM3D_SDK/cmake-3.12.0-rc2-win64-x64/bin/cmake.exe -E copy_if_different
>
>   
> "C:/Users/mjackson/DREAM3D-Dev/DREAM3D/ExternalProjects/SIMPL/Wrapping/Python/Pybind11/../Testing/AbstractFilterTest.py"
>
>   
> "C:/Users/mjackson/DREAM3D-Dev/DREAM3D-Builds/x64/Bin/${CMAKE_CFG_INTDIR}/python/site-packages/AbstractFilterTest.py")
>
>
>
> Which does not work. The files end up in 
> ${BUILD_DIR}/Bin/python/site-packages/. I need them to end up in 
> ${BUILD_DIR}/Bin/Release/python/site-packages for a Release build. Same for 
> Debug…
>
>
>
> Could someone tell me what I am doing wrong or the proper way to go about 
> this? I am about ready to write a simple C++ program to do the copy for me 
> (which seems ludicrous to have to do..)
>
> --
>
> Michael Jackson | Owner, President
>
>   BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] how do you allow CMAKE_CUDA_COMPILER to be optional via project LANGUAGE?

[Robert Maynard]

The way Eric suggest with check_language is what I use when I want to
conditionally support CUDA.

On Tue, Aug 28, 2018 at 10:28 AM Eric Noulard 
wrote:

>
>
> Le mar. 28 août 2018 à 19:07, Quang Ha  a écrit :
>
>> Hi all,
>>
>> So this question is again about project(foo LANGUAGES CXX CUDA). Is it
>> possible to switch off CUDA if Cmake couldn't find CUDA compiler? I.e.
>> something along the line:
>>
>
> May be you can only:
>
>   project(foo LANGUAGES CXX)
>
> then
>
> include(CheckLanguage)
> check_language(CUDA)
> if(CMAKE_CUDA_COMPILER)
>   enable_language(CUDA)
> else()
>   message(STATUS "No CUDA compiler found")
> endif()
>
> see doc:
> https://cmake.org/cmake/help/latest/module/CheckLanguage.html
>
>
> Eric
>
>
>> if (CUDA_FOUND)
>>   set_language_to_CUDA_and_CXX
>> else(CUDA_FOUND)
>>   set_language_to_CXX_only
>> endif(CUDA_FOUND)
>>
>> The main reason is I don't want CMake to fail when CUDA compiler isn't
>> available. Rather, it should continue to compile the source files using CPP
>> compilers instead.
>>
>> Thanks,
>> Quang
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
>
> --
> Eric
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.0 available for download

[Robert Maynard]

module has learned to export the found
  libraries with full path for direct consumption with the
  "target_link_libraries()" command.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.

* The "UseSWIG" module gained a whole refresh and is now more
  consistent with standard CMake commands to generate libraries and is
  fully configurable through properties.

* The "UseSWIG" module learned to manage multiple behaviors through
  "UseSWIG_MODULE_VERSION" variable to ensure legacy support as well
  as more robust handling of "SWIG" advanced features (like
  "%template").

* The "UseSWIG" module learned to support CSHARP variant wrapper
  files.

* The "WriteCompilerDetectionHeader" module gained a "BARE_FEATURES"
  option to add a compatibility define for the exact keyword of a new
  language feature.


Generator Expressions
-

* A new "$" and "$"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$" "generator expression" has been added.

* A new "$" "generator expression" has been
  added.

* A new "$" "generator expression" has
  been added.


CTest
-

* The "ctest_start()" command has been reworked so that you can
  simply call "ctest_start(APPEND)" and it will read all the needed
  information from the TAG file. The argument parsing has also been
  relaxed so that the order of the arguments is less significant.

* A "PROCESSOR_AFFINITY" test property was added to request that
  CTest run a test with CPU affinity for a set of processors disjoint
  from other concurrently running tests with the property set.


CPack
-

* The "CPack" module now uses variables
  "CMAKE_PROJECT_VERSION_MAJOR", "CMAKE_PROJECT_VERSION_MINOR" and
  "CMAKE_PROJECT_VERSION_PATCH" to initialize corresponding CPack
  variables.

* "cpack(1)" gained basic support for NuGet. See the "CPackNuGet"
  module.


Other
-

* The "Compile Features" functionality is now aware of C++ 20.  No
  specific features are yet enumerated besides the "cxx_std_20" meta-
  feature.

* The "Compile Features" functionality is now aware of the
  availability of C features in MSVC since VS 2010.

* The "Compile Features" functionality is now aware of C language
  standards supported by Texas Instruments C compilers.


Deprecated and Removed Features
===

* The "Visual Studio 8 2005" generator has been removed.

* CMake no longer produces "_LIB_DEPENDS" cache entries for
  library targets.  See policy "CMP0073".


Other Changes
=

* Include flags for directories marked as "SYSTEM" are now moved
  after non-system directories.  The "-isystem" flag does this
  automatically, so moving them explicitly to the end makes the
  behavior consistent on compilers that do not have any "-isystem"
  flag.

* Fortran dependency scanning now supports dependencies implied by
  Fortran Submodules.

* The existence and functionality of the file
  "${CMAKE_BINARY_DIR}/cmake_install.cmake" has now been documented in
  the "install()" documentation so that external packaging software
  can take advantage of CPack-style component installs.

* The "CheckIncludeFile" module "check_include_file" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFileCXX" module "check_include_file_cxx" macro
  learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "CheckIncludeFiles" module "check_include_files" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable. See policy
  "CMP0075".

* The "cmake(1)" "-E copy_directory" tool now fails when the source
  directory does not exist.  Previously it succeeded by creating an
  empty destination directory.

* The "UseSWIG" module "swig_add_library()" command (and legacy
  "swig_add_module" command) now set the prefix of Java modules to
  """" for MINGW, MSYS, and CYGWIN environments.


Changes made since CMake 3.12.0-rc3:

Brad King (2):
  Help: Mention IMPORTED_OBJECTS in add_library docs
  CMake 3.12.0

Christian Pfeiffer (1):
  Intel: Fix incorrectly documented extension flags

Cristian Adam (1):
  QNX: Fix autogen compiler predefines detection

Robert Maynard (1):
  Help: Add OBJECT_LIBRARY to TYPE target property documentation

Roger Leigh (2):
  FindBoost: Add support for Boost 1.68 beta1
  FindBoost: Change context header used
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.12 rc2 to rc3 Regression

[Robert Maynard]

The original author of the feature is looking at how to solve this
problem. The author has a post on the developer boards on some of the
changes needed to get everything to work:
https://cmake.org/pipermail/cmake-developers/2018-July/030760.html
On Thu, Jul 19, 2018 at 8:04 AM Michael Jackson
 wrote:
>
> Thank you for the links.
>
>
>
> After reading through all the various discussions is there a time line of 
> when the feature will be added back to CMake? Is it a matter of having 
> somebody to work the problem? Is the problem solvable?
>
> --
>
> Michael Jackson | Owner, President
>
>   BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
>
>
> From: Craig Scott 
> Date: Wednesday, July 18, 2018 at 9:40 AM
> To: Michael Jackson 
> Cc: CMake 
> Subject: Re: [CMake] CMake 3.12 rc2 to rc3 Regression
>
>
>
>
>
>
>
> On Wed, Jul 18, 2018 at 11:04 PM, Michael Jackson 
>  wrote:
>
> Searching the mailing list archives for the RC3 announcement I scrolled to 
> the bottom and found:
>
> Brad King (2):
>   Revert "target_link_libraries: Allow use with targets in other
> directories"
>   CMake 3.12.0-rc3
>
> Just curious what caused the issue to revert the change?
>
>
>
>
>
> The original problem report was on the dev mailing list:
>
>
>
> https://cmake.org/pipermail/cmake-developers/2018-June/030740.html
>
>
>
>
>
> The longer history of how the feature evolved and was then reverted can be 
> found here:
>
>
>
> https://gitlab.kitware.com/cmake/cmake/issues/17943
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>
>
>
> New book released: Professional CMake: A Practical Guide
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.2 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.12.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.12.2 since 3.12.1:

Brad King (5):
  Android: Add support for NDK r18
  CheckIPOSupported: Simplify result reporting logic
  CheckIPOSupported: Tolerate backslashes in output of failed checks
  VS: Restore CMakeLists.txt references in each target
  CMake 3.12.2

Craig Scott (2):
  EXPORT_PROPERTIES: Add test for an undefined property
  EXPORT_PROPERTIES: Prevent null dereference for undefined property

David Demelier (1):
  Help: Fix typo in clang-tidy example -checks option

Igor Kostenko (1):
  FindBoost: Fix context discovery for 1.60 and below

Kenta Kubo (1):
  FindCUDA: Do not find cublas_device on CUDA >= 9.2

Raffi Enficiaud (1):
  FindMatlab: Remove erroneous duplicate code

Robert Maynard (1):
  CUDA: Avoid using deprecated cublas_device to identify device lib dirs

Shane Parris (1):
  cmState: Clear GlobVerificationManager state on Reset
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Specifying path of nvcc for CUDA projects using project command

[Robert Maynard]

You can specify the location by setting the CUDACXX environment
variable ( https://cmake.org/cmake/help/v3.12/envvar/CUDACXX.html ).
On Mon, Sep 10, 2018 at 2:40 PM Jeffrey Perez via CMake  wrote:
>
> Hello,
>
>
>
> I have a project which uses the CMake 3.10.1 and CUDA nvcc compiler and I am 
> using the new project(projectName LANGUAGES CUDA) instead of 
> find_package(CUDA) to do so. I want CMake to use a different (explicitly 
> defined) path for nvcc compiler than the installed version. Before calling 
> project(projectName LANGUAGES CUDA), I declare CUDA_TOOLKIT_ROOT_DIR via an 
> include of a file which defines our third party library variables, but it 
> always finds the installed version. I know that CUDA_TOOLKIT_ROOT_DIR  was 
> meant for the find_package(CUDA) script, but the documentation doesn't seem 
> to specify how to use the new project method of including nvcc.
>
>
>
> Is there a way to specify a different nvcc location using the new format?
>
>
>
> Excerpt from CMakeLists.txt:
>
> …
>
> include(${CMAKE_CURRENT_SOURCE_DIR}/../../../build/thirdparty_versions.cmake) 
> #defines CUDA_TOOLKIT_ROOT_DIR to specified CUDA root with bin/nvcc below it.
>
> message(---CUDA_TOOLKIT_ROOT_DIR:${ CUDA_TOOLKIT_ROOT_DIR})
> project(projectName LANGUAGES CUDA)
>
> …
>
>
>
> Below is a portion of my output:
>
> …
>
> ---CUDA_TOOLKIT_ROOT_DIR:C:/thirdparty/CUDA/v8.0
>
> -- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.17134.
>
> -- The CUDA compiler identification is NVIDIA 8.0.44
>
> -- Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing 
> Toolkit/CUDA/v8.0/bin/nvcc.exe
>
>
>
> You can see that the CUDA compiler found was the intalled version, not 
> C:/thirdparty/CUDA/v8.0
>
>
>
> Thanks,
>
> Jeff Perez
>
>
>
> -- WARNING - CONFIDENTIAL INFORMATION: The information contained in the 
> e-mail may contain confidential and privileged information and is intended 
> solely for the use of the intended recipient(s). Access for any review, 
> re-transmission, dissemination or other use of, or taking of any action in 
> regard and reliance upon this e-mail by persons or entities other than the 
> intended recipient(s) is unauthorized and prohibited. If you are not the 
> intended recipient, please contact the sender by reply e-mail and destroy all 
> copies of the original message and any attachments.
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] are target_compile_definitions not transitive in cmake 3.12.1?

[Robert Maynard]

target_compile_definitions is transitive for PUBLIC/INTERFACE definitions.
Can you provide an example where that is failing?


On Thu, Aug 30, 2018 at 6:32 PM Mario Emmenlauer 
wrote:

>
> Sorry if this has been discussed before, I searched the mailing
> list and google but could not find this exact issue (only [1] and
> [2] that refer to library dependencies).
>
> I have a case where it seems target_compile_definitions() is not
> transitive (it is not passed down via libraries), is that possible?
> I have a project that sets a PUBLIC definition on libA, and during
> the build of libB that links libA the definition is applied. But the
> definition does not pass down to executables linking libB. This is
> confusing for me because library dependencies and includes seem to
> be transitive (linking libB also links libA automatically).
>
> Is it by design that target_compile_definitions() is not transitive
> in cmake 3.12.1? Or am I doing something wrong?
>
> [2] https://gitlab.kitware.com/cmake/cmake/issues/17633
> [1] https://gitlab.kitware.com/cmake/cmake/issues/12435
>
> All the best,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Joining an OBJECT and a SHARED library

[Robert Maynard]

I believe what you are looking for in the CMake 3.12 improvements to
object libraries. In 3.12  the target_link_libraries command now
supports linking to an object library to embed the object files ( only
on direct dependencies, no propagation of .objs ) and also propagates
usage requirements like any other library.


On Wed, Sep 5, 2018 at 12:27 PM George PF  wrote:
>
> Hi,
>
> is there a way to "join" an the OBJECT library with a SHARED library it 
> creates?
>
> The abclib and its component abc_tmp, all .c file have #include "foo.h":
>
> add_library(abc_tmp OBJECT z1. z2.c)
> # generate...
> add_library(abclib SHARED $ generated.c)
>
> Then adding the library foo, which adds the include path to "foo.h" - but 
> this only
> works for 'generated.c', the include path for z1/z1 is not extended:
>
> target_link_libraries(abclib PUBLIC foo)
>
> Repeating the same for 'abc_tmp' is really cumbersome, I want to this to 
> apply to everything
> which goes into creating the abclib, directly or indirectly, is that possible?
>
>
> Regards
>
> GPF
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Lib prefix: Windows vs. Unix/MinGW convention

[Robert Maynard]

>Why isn't CMake doing that by default? The convention of the target
platform should prevail over the convention of the toolchain, shouldn't it?'

CMake considers the target platform to be composed of the OS, and the
compilation toolchain. Therefore MINGW uses the 'lib' prefix.

> 2. Should I use if(WIN32) rather than if(MINGW)?

No if you are using a Microsoft compiler/toolchain than the prefix is
already empty.

On Tue, Jul 10, 2018 at 3:27 AM Olivier Croquette 
wrote:

> Hello,
>
> some projects I am working on are built using CMake and MinGW on
> Windows. It works fine, unfortunately there are come inconsistencies
> regarding the names of the generated libraries. Some are prefixed with
> "lib" like on Unix systems, some are not, like usual on Windows.
>
> It seems that this can be controlled easily by adding the following
> lines in the top CMakeLists.txt:
>
> if(MINGW)
>set(CMAKE_SHARED_LIBRARY_PREFIX "")
>set(CMAKE_STATIC_LIBRARY_PREFIX "")
> endif()
>
> As a CMake beginner, I still have some questions though:
>
> 1. Are there some side-effects? For instance, can it cause libraries not
> to be found when using them across projects?
>
> 2. Should I use if(WIN32) rather than if(MINGW)?
>
> 3. Why isn't CMake doing that by default? The convention of the target
> platform should prevail over the convention of the toolchain, shouldn't it?
>
> Thanks!
>
> Olivier
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Using CMake to link C++ and CUDA Object file

[Robert Maynard]

if you are using the new first class cuda language, as seen by `project(MyTest
LANGUAGES CXX CUDA)` you shouldn't use the old find cuda package or the
associated cuda_add_library calls. When using the first class cuda language
simply use add_library.

The other difference I notice is that you makefile example is not building
shared libraries but object files, so to the same in CMake you need to use
'add_library' with the OBJECT keyword not the SHARED keyword.



On Fri, Jul 6, 2018 at 12:01 AM Quang Ha  wrote:

> Hi all,
>
> Following upon how to perform code linking between CUDA and C++ (here at
> https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
> I have successfully come up with a Makefile that is currently working for
> my test case:
>
> ##Makefile###
> ##
> main_objects = main.o
> host_objects = host.o
> device_objects = device.o
>
> all: $(main_objects) $(host_objects) $(device_objects)
> g++ -O3 -fopenmp $(main_objects) $(host_objects) $(device_objects)
> -L/usr/local/cuda/lib64 -lcudart -o main
>
> $(main_objects): $(main_objects:.o=.cpp)
> g++ -O3 -I/usr/local/cuda/include -c $< -o $@
>
> $(host_objects): $(host_objects:.o=.cpp)
> g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c $<
> -o $@
>
> $(device_objects): $(device_objects:.o=.cu)
> nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $< -o
> $@
>
> clean:
> rm -f *.o main
> 
> ##
>
> Now, I am trying to write a CMake for this, my current attempt is as
> followed:
>
>
> ##CMakeLists.txt
> cmake_minimum_required(VERSION 3.8)
> project(MyTest LANGUAGES CXX CUDA)
>
> # check requirements
> find_package(CUDA REQUIRED)
> find_package(OpenMP)
>
> if (CUDA_FOUND AND OPENMP_FOUND)
> # OpenMP
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
> ${OpenMP_EXE_LINKER_FLAGS}")
>
> # CUDA
> include_directories(${CUDA_INCLUDE_DIRS})
> set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
> ${CUDA_cublas_LIBRARY})
> set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
> set(CUDA_SEPARABLE_COMPILATION OFF)
> set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>
> set(OMP_SOURCES host.cpp)
> add_library(Host_OMP SHARED ${OMP_SOURCES})
> set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
> "-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
> set(LIBS ${LIBS} ${Host_OMP})
>
> set(CUDA_SOURCES device.cu)
> cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
> set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
> set_target_properties(Device_CUDA PROPERTIES
> CUDA_SEPERABLE_COMPILATION ON)
> set(LIBS ${LIBS} ${Device_CUDA})
>
> add_executable(main main.cpp)
> target_link_libraries(main ${LIBS})
>
> endif(CUDA_FOUND AND OPENMP_FOUND)
> 
> ##
>
> It is still, unfortunately, not working. If I commented out the
> add_executable line, the object code for Host_OMP and Device_CUDA is
> compiled. I can then use the terminal and link them with main.cpp using gcc
> and generate the executable - i.e. using the final command in the Makefile
> above.
>
> What am I doing wrong here? It seems to be very fundamental, but I can't
> seem to get it right...
>
> Any suggestions would be greatly appreciated!!
>
> Thanks,
> Quang
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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 

Re: [CMake] Using CMake to link C++ and CUDA Object file

[Robert Maynard]

To be clear the FindCUDA module currently does two things it finds the
location of the CUDA SDK and it also adds the 'cuda_' commands.

In your case you might still need to use FindCUDA to find the location of
the thrust include directory, or you can find the location yourself by
using find_path like:

```
find_path(CUDA_TOOLKIT_INCLUDE
  device_functions.h # Header included in toolkit
  PATHS ${CMAKE_CUDA_IMPLICIT_LINK_DIRECTORIES}
  PATH_SUFFIXES include ../include
  NO_DEFAULT_PATH
  )
```


On Fri, Jul 6, 2018 at 11:30 AM Quang Ha  wrote:

> Thanks for your response, Robert. If I don't use find_package(CUDA), I run
> into the following problem:
>
>  fatal error: thrust/host_vector.h: No such file or directory
>
> I guess this is needed if I am using Thrust/CUDA?
>
> Thanks,
> Quang
>
> On Fri, 6 Jul 2018 at 06:38, Robert Maynard 
> wrote:
>
>> if you are using the new first class cuda language, as seen by 
>> `project(MyTest
>> LANGUAGES CXX CUDA)` you shouldn't use the old find cuda package or the
>> associated cuda_add_library calls. When using the first class cuda
>> language simply use add_library.
>>
>> The other difference I notice is that you makefile example is not
>> building shared libraries but object files, so to the same in CMake you
>> need to use 'add_library' with the OBJECT keyword not the SHARED keyword.
>>
>>
>>
>> On Fri, Jul 6, 2018 at 12:01 AM Quang Ha  wrote:
>>
>>> Hi all,
>>>
>>> Following upon how to perform code linking between CUDA and C++ (here at
>>> https://devblogs.nvidia.com/separate-compilation-linking-cuda-device-code/),
>>> I have successfully come up with a Makefile that is currently working for
>>> my test case:
>>>
>>> ##Makefile###
>>> ##
>>> main_objects = main.o
>>> host_objects = host.o
>>> device_objects = device.o
>>>
>>> all: $(main_objects) $(host_objects) $(device_objects)
>>> g++ -O3 -fopenmp $(main_objects) $(host_objects)
>>> $(device_objects) -L/usr/local/cuda/lib64 -lcudart -o main
>>>
>>> $(main_objects): $(main_objects:.o=.cpp)
>>> g++ -O3 -I/usr/local/cuda/include -c $< -o $@
>>>
>>> $(host_objects): $(host_objects:.o=.cpp)
>>> g++ -O3 -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP -fopenmp -c
>>> $< -o $@
>>>
>>> $(device_objects): $(device_objects:.o=.cu)
>>> nvcc -O3 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA -c $<
>>> -o $@
>>>
>>> clean:
>>> rm -f *.o main
>>> 
>>> ##
>>>
>>> Now, I am trying to write a CMake for this, my current attempt is as
>>> followed:
>>>
>>>
>>> ##CMakeLists.txt
>>> cmake_minimum_required(VERSION 3.8)
>>> project(MyTest LANGUAGES CXX CUDA)
>>>
>>> # check requirements
>>> find_package(CUDA REQUIRED)
>>> find_package(OpenMP)
>>>
>>> if (CUDA_FOUND AND OPENMP_FOUND)
>>> # OpenMP
>>> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
>>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
>>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
>>> ${OpenMP_EXE_LINKER_FLAGS}")
>>>
>>> # CUDA
>>> include_directories(${CUDA_INCLUDE_DIRS})
>>> set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
>>> ${CUDA_cublas_LIBRARY})
>>> set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
>>> set(CUDA_SEPARABLE_COMPILATION OFF)
>>> set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
>>>
>>> set(OMP_SOURCES host.cpp)
>>> add_library(Host_OMP SHARED ${OMP_SOURCES})
>>> set_target_properties(Host_OMP PROPERTIES COMPILE_FLAGS
>>> "-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_OMP")
>>> set(LIBS ${LIBS} ${Host_OMP})
>>>
>>> set(CUDA_SOURCES device.cu)
>>> cuda_add_library(Device_CUDA SHARED ${CUDA_SOURCES})
>>> set_target_properties(Device_CUDA PROPERTIES COMPILE_FLAGS
>>> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
>>> set_target_properties(Device_CUDA PROPERTIES
>>> CUDA_SEPERABLE_COMPILATION ON)
>>> set(LIBS ${LIBS} ${

Re: [CMake] Concurrency issues with copy_if_different

[Robert Maynard]

Personally would go with option number 2

On Thu, Jul 12, 2018 at 1:58 AM Olivier Croquette 
wrote:

> Hello,
>
> in one of our projects, we use copy_if_different to copy some DLLs
> required by the runtime. It's called as post-build action. The problem
> is that several targets want to copy the same DLLs, and when using
> parallelized builds, the different "cmake -E copy_if_different" can
> conflict, leading the whole build to fail.
>
> I see two options to fix this:
>
> 1. don't use copy_if_different, but a custom tool that can deal with the
> concurrency
>
> 2. instead of adding post-build actions to different targets, fill up a
> list containing all the files required, and add a single post-build
> action to a single target that copies all the required files in one go
>
> What do you think?
>
> Cheers
> Olivier
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.12.0-rc3 is ready for testing

[Robert Maynard]

I am proud to announce the third CMake 3.12 release candidate.
  https://cmake.org/download/

The first two 3.12.0 release candidates included a change to allow
the target_link_libraries command to modify targets created outside
the current directory. This has been reverted in rc3 due to
problems with visibility of the linked targets. See issue 17943.

Documentation is available at:
  https://cmake.org/cmake/help/v3.12

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.12/release/3.12.html

Some of the more significant changes in CMake 3.12 are:

* The "target_link_libraries()" command now supports Object
  Libraries. Linking to an object library uses its object files in
  direct dependents and also propagates usage requirements.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "Compile Features" functionality is now aware of C++ 20.  No
  specific features are yet enumerated besides the "cxx_std_20" meta-
  feature.

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.

* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* A new "$" and "$"
  "generator expression" has been added to enable consumption of
  generator expressions whose evaluation results itself in generator
  expressions.

* A new "$" "generator expression" has been
  added.

* A new "$" "generator expression" has
  been added.

* The "FindCURL" module now provides imported targets.

* The "FindJPEG" module now provides imported targets.

* A "FindODBC" module was added to find an Open Database
  Connectivity (ODBC) library.

* New "FindPython3" and "FindPython2" modules, as well as a new
  "FindPython" module, have been added to provide a new way to locate
  python environments.


CMake 3.12 Release Notes


Changes made since CMake 3.11 include the following.


New Features



Generators
--

* The Visual Studio Generators for VS 2017 learned to support a
  "version=14.##" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g.
  via the "cmake(1)" "-T" option) to specify a toolset version number.


Command-Line


* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  parallel []" and "-j []" options to specify a parallel
  build level.  They map to corresponding options of the native build
  tool.


Commands


* The "add_compile_definitions()" command was added to set
  preprocessor definitions at directory level.  This supersedes
  "add_definitions()".

* The "cmake_minimum_required()" and "cmake_policy(VERSION)"
  commands now accept a version range using the form
  "[...]". The "" version is required but policies are
  set based on the "" version.  This allows projects to specify a
  range of versions for which they have been updated and avoid
  explicit policy settings.

* The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new
  flag "CONFIGURE_DEPENDS" which enables expression of build system
  dependency on globbed directory's contents.

* The "file(TOUCH)" and "file(TOUCH_NOCREATE)" commands were added
  to expose "TOUCH" functionality without having to use CMake's
  command- line tool mode with "execute_process()".

* The "find_package()" command now searches a prefix specified by a
  "PackageName_ROOT" CMake or environment variable.  Package roots are
  maintained as a stack so nested calls to all "find_*" commands
  inside find modules also search the roots as prefixes. See policy
  "CMP0074".

* The "install()" command learned an optional "NAMELINK_COMPONENT"
  parameter, which allows you to change the component for a shared
  library's namelink. If none is specified, the value of "COMPONENT"
  is used by default.

* The "list()" command learned a "JOIN" sub-command to concatenate
  list's elements separated by a glue string.

* The 

Re: [CMake] CMake tried to pass all flags from gcc into nvcc when trying to add CUDA extension to current CPP project

[Robert Maynard]

The `CUDA_PROPAGATE_HOST_FLAGS` and `CUDA_SEPARABLE_COMPILATION` are global
variables ( use `set` ) not a target properties. You can find more
documentation on the legacy cuda support variable in the find cuda module (
https://cmake.org/cmake/help/latest/module/FindCUDA.html ).

On Mon, Jul 9, 2018 at 9:52 AM Quang Ha  wrote:

> Hi all,
>
> The situation I am currently in is as followed. This is the directory for
> my project:
>
> project
> |--CMakeLists.txt
> |--app
> ||CMakeLists.txt
> ||test_cuda
> |  |CMakeLists.txt
> |  |test_cuda.cu
> |--src
> |--test
> |--doc
>
> Inside project/app/CMakeLists.txt, it looks like this:
> ##
> add_subdirectory(test_cuda)
> ##
> and then inside project/app/test_cuda/CMakeLists.txt, it is:
> ##
> find_package(CUDA REQUIRED)
>
> if (CUDA_FOUND)
> # CUDA falgs
> include_directories(${CUDA_INCLUDE_DIRS})
> set(ALL_CUDA_LIBS ${CUDA_LIBRARIES} ${CUDA_cusparse_LIBRARY}
> ${CUDA_cublas_LIBRARY})
> set(LIBS ${LIBS} ${ALL_CUDA_LIBS})
> set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};--maxrregcount 32)
> # set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS};-gencode
> arch=compute_70,code=sm_70)
>
> # Link to executable
> cuda_add_executable(test_cuda test_cuda.cu)
> # set_target_properties(test_cuda PROPERTIES COMPILE_FLAGS
> "-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA")
> set_target_properties(test_cuda PROPERTIES CUDA_SEPARABLE_COMPILATION
> ON)
> set_target_properties(test_cuda PROPERTIES CUDA_PROPAGATE_HOST_FLAGS
> OFF)
> target_link_libraries(test_cuda ${LIBS} ${EXTRA_LIBS})
> endif()
> ##
>
> There is nothing special inside test_cuda.cu - since I just want to test
> cmake integration:
> ##
> #include 
> #include 
>
> __global__
> void kernel (void){
> }
>
> int main(void ) {
>   kernel<<<1,1>>>();
>   return 0;
> }
> ##
>
> I got an error when running cmake with this:
>
> ###
> [ 75%] Building NVCC (Device) object
> app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(200):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(202):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(224):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(226):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(246):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(248):
> error: a constexpr function must contain exactly one return statement
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(268):
> error: statement may not appear in a constexpr function
>
> /projects/opt/centos7/gcc/6.4.0/include/c++/6.4.0/bits/stl_algobase.h(270):
> error: a constexpr function must contain exactly one return statement
>
> 8 errors detected in the compilation of
> "/tmp/tmpxft_3241_-4_test_cuda.cpp4.ii".
> CMake Error at test_cuda_generated_test_cuda.cu.o.Release.cmake:279
> (message):
>   Error generating file
>
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> ###
>
> Checking with make VERBOSE=1:
>
> ##
> [ 75%] Building NVCC (Device) object
> app/test_cuda/CMakeFiles/test_cuda.dir/test_cuda_generated_test_cuda.cu.o
> cd
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E make_directory
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//.
> cd
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir &&
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -D verbose:BOOL=1 -D
> build_configuration:STRING=Release -D
> generated_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> -D
> generated_cubin_file:STRING=/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o.cubin.txt
> -P
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.Release.cmake
> -- Removing
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> /projects/opt/centos7/cmake/3.11.1/bin/cmake -E remove
> /home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//./test_cuda_generated_test_cuda.cu.o
> -- Generating dependency file:
> 

[CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing

[Robert Maynard]

I am proud to announce the third CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes


Changes made since CMake 3.10 include the following.


New Features



Platforms
-

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
--

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands


* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
-

* A 

[CMake] [ANNOUNCE] CMake 3.11.0-rc2 is now ready for testing

[Robert Maynard]

I am proud to announce the second CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes


Changes made since CMake 3.10 include the following.


New Features



Platforms
-

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
--

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands


* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
-

* A 

Re: [CMake] CMake misidentifies xlc++ as Clang

[Robert Maynard]

Just to roundtrip this for posterity. The fix for incorrect
identification of XLC will be in CMake 3.11.0-rc3

On Thu, Mar 8, 2018 at 11:17 AM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> Hi.
>
> 1. You can report this issue on the CMake gitlab (
> https://gitlab.kitware.com/cmake/cmake/issues ). You will want to
> attach the result of dumping all defines from the compiler ( xlc++ -dD
> -E - < /dev/null  or xlc++ -dM -E ).  Currently it looks like we are
> using '__IBMCPP__' to detect xlc++, and that might not be defined on
> the power pc platform.
>
> 2. If my guess about about 1 is correct, You can try setting the
> environment variable CXX_FLAGS to -qxlcompatmacros and see if that
> works ( 
> https://www.ibm.com/support/knowledgecenter/SSXVZZ_13.1.3/com.ibm.xlcpp1313.lelinux.doc/compiler_ref/xlmacros.html#xlmacros__suplink1
> )
>
> On Wed, Mar 7, 2018 at 4:22 PM, Thompson, KT <k...@lanl.gov> wrote:
>> Hi,
>>
>>
>>
>> I am using cmake-3.9.4 on a power9 system with CXX=xlc++ (IBM XL C++) and
>> CMake is misidentifying the compiler as "clang".
>>
>>
>>
>> % uname -a
>>
>> Linux cn2021 4.11.0-44.4.1.el7a.ppc64le #1 SMP Sat Dec 9 02:17:51 EST 2017
>> ppc64le ppc64le ppc64le GNU/Linux
>>
>>
>>
>> % echo $CXX
>>
>> xlc++
>>
>>
>>
>> % $CXX --version
>>
>> IBM XL C/C++ for Linux, V13.1.6 (Community Edition)
>>
>> Version: 13.01.0006.0001
>>
>>
>>
>> % cmake ..
>>
>> -- The CXX compiler identification is Clang 4.0.1
>>
>> -- Check for working CXX compiler:
>> /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++
>>
>> -- Check for working CXX compiler:
>> /projects/opt/ppc64le/ibm/xlc-13.1.6/xlC/13.1.6/bin/xlc++ -- works
>>
>> …
>>
>>
>>
>> Because, the compiler_ID is misidentified, inappropriate compiler options
>> are added when CXX_CXX_STANDARD is set (along with other issues).
>>
>>
>>
>> Question 1: How do I report this as a bug? What additional information is
>> needed to characterize the failure mode?
>>
>>
>>
>> Question 2: Is there a way to force the compiler ID to be "XL" as a
>> temporary work around until the bug is fixed?
>>
>>
>>
>> Thank you,
>>
>>
>>
>> -kt
>>
>>
>>
>>
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing

[Robert Maynard]

You are correct the buildsystem documentation is out of date and now
incorrect. So please submit patch.

On Sat, Mar 10, 2018 at 4:03 AM, Kai Wolf <kai.w...@gmail.com> wrote:
> Hey,
>
> it’s nice to see that we’re now able to set include directories and compiler
> flags for imported targets as well apparently.
> This means, no more
>
> add_library(foo UNKNOWN IMPORTED)
> set_target_properties(foo PROPERTIES
>   INTERFACE_INCLUDE_DIRECTORIES …
>   IMPORTED_LOCATION ..)
>
> but using target_* just like for any other target as well
>
> add_library(foo UNKNOWN IMPORTED)
> target_include_directories(foo PUBLIC …)
>
> However, reading through the 3.11 documentation [1] I think I’ve found a bug
> unfortunately:
>
> "It is not possible to use an IMPORTED target in the left-hand-side of the
> target_compile_definitions(), target_include_directories(),
> target_compile_options() or target_link_libraries() commands, as that would
> be an attempt to modify it. IMPORTED targets are designed to be used only in
> the right-hand-side of those commands."
>
> If that’s really the case, I will submit a patch for it right away. I just
> want to make sure, I’m not misunderstanding something here?
>
> Greetings,
>
> Kai Wolf
> http://kai-wolf.me/
>
> [1]
> https://cmake.org/cmake/help/v3.11/manual/cmake-buildsystem.7.html?highlight=right%20hand%20side#imported-targets
>
> Am 09.03.2018 um 20:00 schrieb Robert Maynard <robert.mayn...@kitware.com>:
>
> I am proud to announce the third CMake 3.11 release candidate.
>  https://cmake.org/download/
>
> Documentation is available at:
>  https://cmake.org/cmake/help/v3.11
>
> Release notes appear below and are also published at
>  https://cmake.org/cmake/help/v3.11/release/3.11.html
>
> Some of the more significant changes in CMake 3.11 are:
>
> * The Makefile Generators and the "Ninja" generator learned to add
>  compiler launcher tools along with the compiler for the "Fortran"
>  language ("C", "CXX", and "CUDA" were supported previously). See the
>  "CMAKE__COMPILER_LAUNCHER" variable and
>  "_COMPILER_LAUNCHER" target property for details.
>
> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
>  "generator expression" in target-wide "COMPILE_DEFINITIONS",
>  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
>  generator expression documentation for caveats.
>
> * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
>  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
>  "INCLUDE_DIRECTORIES".  It previously supported only
>  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
>  documentation for caveats.
>
> * "add_library()" and "add_executable()" commands can now be called
>  without any sources and will not complain as long as sources are
>  added later via the "target_sources()" command.
>
> * The "target_compile_definitions()" command learned to set the
>  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.
>
> * The "target_compile_features()" command learned to set the
>  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.
>
> * The "target_compile_options()" command learned to set the
>  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.
>
> * The "target_include_directories()" command learned to set the
>  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.
>
> * The "target_sources()" command learned to set the
>  "INTERFACE_SOURCES" property on Imported Targets.
>
> * The "target_link_libraries()" command learned to set the
>  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.
>
> * The "COMPILE_DEFINITIONS" source file property learned to support
>  "generator expressions".
>
> * A "COMPILE_OPTIONS" source file property was added to manage list
>  of options to pass to the compiler.
>
> * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
>  parallel "moc" or "uic" processes to reduce the build time. A new
>  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
>  property may be set to specify the number of parallel "moc" or "uic"
>  processes to start.  The default is derived from the number of CPUs
>  on the host.
>
>
> CM