[Cmake-commits] CMake branch, master, updated. v3.12.0-rc3-167-gbe69317

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  be69317b971dd381fe771701aa9ed944416e26c6 (commit)
  from  8d478c0003cc9bb4836038fc1a27d3bbd40348d2 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be69317b971dd381fe771701aa9ed944416e26c6
commit be69317b971dd381fe771701aa9ed944416e26c6
Author: Kitware Robot 
AuthorDate: Tue Jul 10 00:01:07 2018 -0400
Commit: Kitware Robot 
CommitDate: Tue Jul 10 00:01:07 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4a05801..ceac5cb 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 12)
-set(CMake_VERSION_PATCH 20180709)
+set(CMake_VERSION_PATCH 20180710)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Cannot prevent import library from being created with VS generator

[Jason Heeris]

On Tue, 10 Jul 2018 at 09:57, J. Caleb Wherry  wrote:
> Side note 1: Things like this eventually lead me to have a post process
(a python script) on all my VS project files to “fix” any issues like this.

It might interest you to know that I've worked around it a bit by tweaking
the IMPORT_PREFIX property:

set_target_properties(
${modname_dll}
PROPERTIES
OUTPUT_NAME
${module_name}
# Required to work around the fact that we rename our shared
libraries
# to have the same name as our static libraries, so when Visual
Studio's
# linker tries to create an export library, it clashes with an input
# library.
IMPORT_PREFIX
"import_"
)

Cheers,
Jason
-- 

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] Cannot prevent import library from being created with VS generator

[J. Caleb Wherry]

I’m also interested in this.

Side note 1: Things like this eventually lead me to have a post process (a
python script) on all my VS project files to “fix” any issues like this. If
I can’t figure out a way to do something specific in a VS project, I just
add it to my post process until I eventually have time to dig in and figure
it out. For this specific issue, I just match a regex for the line and
remove it. I know this shouldn’t be neccessary but sometimes I just don’t
have the time to figure out a specific generator problem.

Side note 2: I also used this process at one point to make relocatable VS
solutions/projects. It worked quite well and is a quick way to get around
short comings in how CMake creates VS artifacts.

-Caleb

On Mon, Jul 9, 2018 at 6:49 PM Jason Heeris  wrote:

> I'm using CMake 3.12-rc1 on Windows 10. I have the following
> `CMakeLists.txt`:
>
> cmake_minimum_required(VERSION 3.8)
> project(cmake_test)
> unset(CMAKE_IMPORT_LIBRARY_SUFFIX)
> add_library(main MODULE "main.c")
>
> The generator is Visual Studio 15 2017.
>
> I would like to suppress the "/IMPLIB" argument created for the "main"
> library. In my real project, I have static and shared libraries named the
> same. This works fine, because they have different extensions (lib vs dll),
> but a problem arises when the linker tries to create an import library for
> "something.dll" named "something.lib", while also trying to link against a
> static library named "something.lib".
>
> The import library is not needed though; in CMake terminology the DLL is a
> "module" ie. loaded via DllOpen(). The documentation suggested that calling
> "add_library()" with "MODULE" was what I needed here. Unfortunately the
> resulting VS project still contains an import library flag for the linker.
>
> A Stackoverflow answer[1] suggested unsetting
> "CMAKE_IMPORT_LIBRARY_SUFFIX" because the source indicates[2] this will
> stop the flag from appearing. But all this seems to do is drop the filename
> from the generated project; it still contains this now-incorrect flag that
> references a directory instead of a full path:
>
> C:/Users/heerij/Code/cmake-ex-2/build/Debug/
>
> How do I prevent the import library creation?
>
> - Jason
>
>   [1]
> https://stackoverflow.com/questions/34575066/how-to-prevent-cmake-from-issuing-implib
>   [2]
> https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmComputeLinkInformation.cxx#L271
> --
>
> 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
>
-- 
Sent from my iPhone 4s
-- 

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] Cannot prevent import library from being created with VS generator

[Jason Heeris]

I'm using CMake 3.12-rc1 on Windows 10. I have the following
`CMakeLists.txt`:

cmake_minimum_required(VERSION 3.8)
project(cmake_test)
unset(CMAKE_IMPORT_LIBRARY_SUFFIX)
add_library(main MODULE "main.c")

The generator is Visual Studio 15 2017.

I would like to suppress the "/IMPLIB" argument created for the "main"
library. In my real project, I have static and shared libraries named the
same. This works fine, because they have different extensions (lib vs dll),
but a problem arises when the linker tries to create an import library for
"something.dll" named "something.lib", while also trying to link against a
static library named "something.lib".

The import library is not needed though; in CMake terminology the DLL is a
"module" ie. loaded via DllOpen(). The documentation suggested that calling
"add_library()" with "MODULE" was what I needed here. Unfortunately the
resulting VS project still contains an import library flag for the linker.

A Stackoverflow answer[1] suggested unsetting "CMAKE_IMPORT_LIBRARY_SUFFIX"
because the source indicates[2] this will stop the flag from appearing. But
all this seems to do is drop the filename from the generated project; it
still contains this now-incorrect flag that references a directory instead
of a full path:

C:/Users/heerij/Code/cmake-ex-2/build/Debug/

How do I prevent the import library creation?

- Jason

  [1]
https://stackoverflow.com/questions/34575066/how-to-prevent-cmake-from-issuing-implib
  [2]
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmComputeLinkInformation.cxx#L271
-- 

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] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds (SOLVED)

[Alan W. Irwin]

On 2018-07-09 09:10+0200 Nils Gladitz wrote:


On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin 
wrote:


My parallel builds on my Linux OS (currently Debian Buster, but this
also happened for Debian Jessie so this is a long-standing problem)
have ascii null ('\0) characters inserted in the output while the
corresponding non-parallel build does not have those extra characters.



I narrowed it down with Ninja which buffers command outputs in parallel
builds which makes it easier to match output to specific commands.
Alternatively I think CTest launchers might have helped with this too.
CMake uses them to redirect build command outputs to distinct files for
CTest submissions.

I see null bytes coming from the "cat test.error" in the script file
generated from
https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in

If this only shows up in parallel builds perhaps multiple processes are
reading/writing the same test.error file in parallel?
Haven't looked closer than that. You probably know better where to look
from there.


Hi Nils:

Many thanks for going "above and beyond" with this issue.  Indeed,
many of the language test scripts in plplot_test write to "test.error"
and then output it after the command has been run with "cat
test.error".  Many of those test.error files are in the same directory
so this constitutes a many-way name clash and therefore a set of clear race
condition for parallel builds that has existed for at least the last
decade in PLplot.  UGH!

I fixed those nameclashes with PLplot commit a4bada004 (see that log
message for additional commentary), and the extra '\0' characters in
parallel output are now gone.  I have no idea why the symptom of the
race is the extra '\0' characters, but I am just happy to have these
symptoms as well as the race conditions fixed!

Thanks for your key help in leading me to the solution of
this long-standing PLplot build-system issue.

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

Re: [CMake] How to specify library dir for imported interface?

[Francis Giraldeau]

Le mer. 4 juil. 2018 à 10:43, Marc CHEVRIER  a
écrit :

> Next version of CMake (3.13) will supports properties LINK_OPTIONS as well
> as INTERFACE_LINK_OPTIONS.
>

Interesting, will it fix the issue with pkg-config? When installed in a
non-standard directory, pkg-config will return the library dir. Here is an
example with libsodium:

$ PKG_CONFIG_PATH=/tmp/bidon/lib/pkgconfig pkg-config --libs libsodium
-L/tmp/bidon/lib -lsodium

At first, the property INTERFACE_LINK_DIRECTORIES would make sens. Would
there be some drawbacks to specify link directories for imported targets?

Cheers,

Francis
-- 
Francis Giraldeau
-- 

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] When is the TARGET_NAME generator expression necessary?

[Razvan Maris via CMake]

Hello,

I was reading the CMake documentation regarding generator expressions, and I 
found the following:

"$
Marks ... as being the name of a target. This is required if exporting targets 
to multiple dependent export sets. The ... must be a literal name of a target- 
it may not contain generator expressions."

From that I understand that if some targets from an export set depend on other 
targets from other export set, the dependencies should be specified using 
$ instead of the targets' names.
I found the thread (this message specifically: 
https://www.mail-archive.com/cmake-developers@cmake.org/msg05498.html) that is 
responsible for the introduction of the TARGET_NAME generator expression, 
however I cannot find an example for its use.

I believe it has something to do with adding the correct namespace to the 
"required library".

I tried an example of dependent export sets in which I do not use 
$, I even use the target's name inside another generator 
expression, but no error is generated and the output files contain the correct 
"imported" targets (with the correct namespaces):

"project(target_name)
add_library(a a.cpp)
add_library(b b.cpp)

target_link_libraries(b $<$:a>)


export(TARGETS
       a
       NAMESPACE foo_
       FILE a_config.cmake
)
 
export(TARGETS
       b
       NAMESPACE bar_
       FILE b_config.cmake
)"

When are we required to use the TARGET_NAME generator expression?


Thank you,
Razvan
-- 

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] Eclipse CDT4 - Unix Makefiles / Ninja Generator

[Martin Weber]

Am Sonntag, 8. Juli 2018, 23:17:27 CEST schrieb Alexander Neundorf:
> On 2018 M07 7, Sat 19:09:18 CEST Martin Weber wrote:
> > Hi all,
> > 
> > FYI, according to this [1], those generators do no longer work with the
> > new
> > core build introduced in CDT 9.5.
> > 
> > Martin
> > 
> > [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html
> 
> do you know whether the new build system of CDT is documented somewhere ?
> I found this, but this is far from enough.
> http://www.eclipse.org/org/langsymp/CDT%20Managed%20Build%20System.pdf

All I found is here 

I also browsed through the new code, but the javadocs are close to non-
existent.

If the cmake devs plan to remove the CDT4 generator, I think that would be OK. 
In 2013, I started an eclipse plugin that automatically runs cmake from 
Eclipse. It's also in the marketplace, so cmake users have an escape.

Martin

-- 
Cd wrttn wtht vwls s mch trsr.


-- 

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 for license file for commercial compiler?

[Alan W. Irwin]

On 2018-07-09 12:48- Clune, Thomas L. (GSFC-6101) wrote:

[...]

Based upon conversations with colleagues in other institutions, the

  most frustrating compiler is always the one you don’t do your
  development with.  Because of my clients, I mostly start with Intel
  and then get frustrated when a design discovers defects in gfortran.
  But others that primarily work with gfortran say the same about
  Intel.  My conclusion as that we subconsciously develop a coding
  style this is (mostly) robust within our native environment.

I agree with your overall conclusion (and many other interesting
points you made which I didn't quote).


When the situation permits, I mostly develop with the NAG fortran

  compiler.  The generated code is not particularly fast, but the
  compiler is very strict and very robust.

I have no experience with that compiler myself, but a colleague has
taken advantage of its well-known strictness to make sure the Fortran
binding of the PLplot C library (which is implemented using the
iso_c_binding module) is fully compliant with the Fortran 2003
standard with run-time results that pass our Fortran tests (which
demand that our standard set of 33 plot examples written in Fortran
2003 give identical results to the corresponding C examples).  He has
also achieved similar testing success with ifort, and I have done the
same with gfortran.  So with PLplot, those three Fortran compilers
give perfect test results and although we haven't yet had the time to
look at other Fortran compilers presumably most of them will also
produce perfect test results (since most Fortran vendors report they
have correctly implemented all parts of the iso_c_binding module).

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

Re: [CMake] find_package: keyword REQUIRED ignored

[Rolf Eike Beer]

Am Montag, 9. Juli 2018, 09:45:25 CEST schrieb Mark De Wit:
> I thought that the find script itself was responsible for checking the
> required flag?

That's what find_package_handle_standard_args() does.

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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 

[cmake-developers] [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:
> 

Re: [CMake] wix msi csharp dotnet project type

[J. Caleb Wherry]

If you set the WIN32_EXECUTABLE property on your WPF target then it will
have the behavior you are looking for.

-Caleb

On Mon, Jul 9, 2018 at 10:58 AM Petar Petrov 
wrote:

> I have gone through the cmake wix docs and in particular anything special
> about dotnet csharp projects, however I failed to find anything related to
> influencing the 'Output Type' of project's settings window inside visual
> studio!
>
> The options are: 'Console Application, Windows Application and Class
> Library', the generator defaults to Console Application while I do have a
> WPF windows only app, so I have an annoying console/terminal window in
> addition to the main-win. There are plenty of possible hack to influence
> the generated project file directly (which just a xml) but it is truly a
> job of the wix generator and I expected to be an easy straightforward way
> of setting it.
>
> Any tips and suggestions are welcomed!
>
> Thanks in advance,
> Peter
> --
>
> 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
>


-- 
J. Caleb Wherry
*Scientific Software Engineer*


http://www.calebwherry.com
+1 (615) 708-5651
calebwhe...@gmail.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:
https://cmake.org/mailman/listinfo/cmake

[CMake] wix msi csharp dotnet project type

[Petar Petrov]

I have gone through the cmake wix docs and in particular anything special
about dotnet csharp projects, however I failed to find anything related to
influencing the 'Output Type' of project's settings window inside visual
studio!

The options are: 'Console Application, Windows Application and Class
Library', the generator defaults to Console Application while I do have a
WPF windows only app, so I have an annoying console/terminal window in
addition to the main-win. There are plenty of possible hack to influence
the generated project file directly (which just a xml) but it is truly a
job of the wix generator and I expected to be an easy straightforward way
of setting it.

Any tips and suggestions are welcomed!

Thanks in advance,
Peter
-- 

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-commits] CMake branch, master, updated. v3.12.0-rc3-166-g8d478c0

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  8d478c0003cc9bb4836038fc1a27d3bbd40348d2 (commit)
   via  c878e6f8cc89ae5864d3446bf237bf53f1ee6563 (commit)
   via  67ae6da331d4c7fbcb810982077922bae54a (commit)
   via  2a5f5c0e316d415e1b8207348b34761d34f191ae (commit)
   via  12e6f83319d089b3295b4211d0d4810575e8f7d5 (commit)
   via  5bb3d40a289c44f350aa68f32e5ef0c1ad7f13b1 (commit)
  from  1b5b1dc5cc5d1fd92fafcece3b4ae8ad51fd5817 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d478c0003cc9bb4836038fc1a27d3bbd40348d2
commit 8d478c0003cc9bb4836038fc1a27d3bbd40348d2
Merge: c878e6f 67ae6da
Author: Brad King 
AuthorDate: Mon Jul 9 14:26:35 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jul 9 10:26:40 2018 -0400

Merge topic 'emacs-fix-unescaped-character-literals'

67ae6da331 cmake-mode.el: Fix "unescaped character literals" warning

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c878e6f8cc89ae5864d3446bf237bf53f1ee6563
commit c878e6f8cc89ae5864d3446bf237bf53f1ee6563
Merge: 1b5b1dc 2a5f5c0
Author: Brad King 
AuthorDate: Mon Jul 9 14:25:24 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jul 9 10:25:33 2018 -0400

Merge topic 'option-normal-variable'

2a5f5c0e31 option: respect existing normal variable
12e6f83319 Option: Add a test that verifies interaction with normal 
variables
5bb3d40a28 cmOption: Remove VTK 4.0 workarounds

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

diff --cc Tests/RunCMake/CMakeLists.txt
index c211f99,e55d97d..97c3178
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@@ -238,8 -238,8 +238,9 @@@ add_RunCMake_test(include
  add_RunCMake_test(include_directories)
  add_RunCMake_test(include_guard)
  add_RunCMake_test(list)
 +add_RunCMake_test(math)
  add_RunCMake_test(message)
+ add_RunCMake_test(option)
  add_RunCMake_test(project -DCMake_TEST_RESOURCES=${CMake_TEST_RESOURCES})
  add_RunCMake_test(return)
  add_RunCMake_test(separate_arguments)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67ae6da331d4c7fbcb810982077922bae54a
commit 67ae6da331d4c7fbcb810982077922bae54a
Author: Jeff Kowalski 
AuthorDate: Fri Jul 6 16:56:32 2018 -0700
Commit: Brad King 
CommitDate: Mon Jul 9 10:06:33 2018 -0400

cmake-mode.el: Fix "unescaped character literals" warning

Emacs 27.0 warns

Loading ‘cmake-mode’: unescaped character literals `?(', `?)' detected!

during byte-compilation of cmake-mode.el The new warning was added in
emacs commit c2bbdc3316 (Warn about missing backslashes during load).

Add backslashes to escape the literals.

diff --git a/Auxiliary/cmake-mode.el b/Auxiliary/cmake-mode.el
index 8ae57d4..e4fa6c1 100644
--- a/Auxiliary/cmake-mode.el
+++ b/Auxiliary/cmake-mode.el
@@ -55,7 +55,7 @@ set the path with these commands:
   (* (or (not (any space "()#\\\n")) (and ?\\ nonl)
 (defconst cmake-regex-token
   (rx-to-string `(group (or (regexp ,cmake-regex-comment)
-?( ?)
+?\( ?\)
 (regexp ,cmake-regex-argument-unquoted)
 (regexp ,cmake-regex-argument-quoted)
 (defconst cmake-regex-indented

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a5f5c0e316d415e1b8207348b34761d34f191ae
commit 2a5f5c0e316d415e1b8207348b34761d34f191ae
Author: Robert Maynard 
AuthorDate: Thu Jun 21 14:53:11 2018 -0400
Commit: Brad King 
CommitDate: Mon Jul 9 07:48:28 2018 -0400

option: respect existing normal variable

Add policy CMP0077 to change this behavior in a compatible way.

diff --git a/Help/command/option.rst b/Help/command/option.rst
index 91cd0a7..4fabb87 100644
--- a/Help/command/option.rst
+++ b/Help/command/option.rst
@@ -9,7 +9,9 @@ Provides an option that the user can optionally select.
  [initial value])
 
 Provide an option for the user to select as ``ON`` or ``OFF``.  If no
-initial value is provided, ``OFF`` is used.
+initial value is provided, ``OFF`` is used.  If the option is already
+set as a normal variable then the command does nothing
+(see policy :policy:`CMP0077`).
 
 If you have options that depend on the values of other options, see
 the module help for :module:`CMakeDependentOption`.
diff --git a/Help/manual/cmake-policies.7.rst b/Help/manual/cmake-policies.7.rst
index 6179a7c..b2eeb3a 100644
--- a/Help/manual/cmake-policies.7.rst
+++ b/Help/manual/cmake-policies.7.rst
@@ -57,6 +57,7 @@ 

Re: [cmake-developers] why can target_include_directories() not be applied to custom targets?

[Drew Parsons]

On Mon, 2018-07-09 at 16:02 +0300, Attila Krasznahorkay wrote:
> Hi,
> 
> Just to say that setting INCLUDE_DIRECTORIES on a custom target is
> indeed a bit of an obscure thing, but we do use it. You can find the
> full reasoning in:
> 
> https://gitlab.kitware.com/cmake/cmake/issues/16830
> 
> Because of that, I understood that CMake will provide this
> functionality in the future as well, so we can rely on this build
> setup.
> 
> Cheers,
>   Attila
> 
> > On 8 Jul 2018, at 12:16, Petr Kmoch  wrote:
> > 
> > Hi Drew,
> > 
> > a custom target can do literally anything, it's just a buildsystem
> > wrapper for running arbitrary executables; or often not even that,
> > and is just a collection of custom commands. There is nothing CMake
> > automatically does with the properties
> > [INTERFACE_]INCLUDE_DIRECTORIES set on a custom command.


Thanks for the explanation Petr, and Attila.

Looks like 

  set_property(TARGET mylib PROPERTY INCLUDE_DIRECTORIES 
${CMAKE_CURRENT_SOURCE_DIR})

does what I have in mind, it can stand in place of
target_include_directories() for custom targets.

Drew

-- 

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

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

[Quang Ha]

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:
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
/projects/opt/centos7/cuda/9.1/bin/nvcc -M -D__CUDACC__
/home/qth20/develop/project/app/test_cuda/test_cuda.cu -o
/home/qth20/develop/project/build/app/test_cuda/CMakeFiles/test_cuda.dir//test_cuda_generated_test_cuda.cu.o.NVCC-depend
-ccbin /projects/opt/centos7/gcc/6.4.0/bin/gcc -m64 -DTHRUST
-DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP
-DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_CUDA
"-DCUDA_CALLABLE=\"__host__ __device__\"" -Xcompiler
,\"-std=c++14\",\"-O3\",\"-DNDEBUG\" 

[Cmake-commits] CMake annotated tag, v3.12.0-rc3, created. v3.12.0-rc3

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The annotated tag, v3.12.0-rc3 has been created
at  03ff07ae692ae37b41ae8bd2790f9eb6c00aa4ad (tag)
   tagging  7f1569d2d8c1a647cf4d1b0696834952cf8f00fb (commit)
  replaces  v3.12.0-rc2
 tagged by  Brad King
on  Mon Jul 9 09:30:19 2018 -0400

- Log -
CMake 3.12.0-rc3
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAltDY2sWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhBYhD/wMEEJX4hpLWSDB/96PXNEysdHF
aK0TBvpwuEHzg/GRMsFDs4w8SQXsjWiNUdc3wS6Uhpwg2V8kLfYB9OEpTQt6eGif
nS39/1C4ZwnR7m+z4fPI25wxfn0mMs6X515w6iV3FrRahHA8Pe1a6vaaqEzg5+Gu
lyzFtLJaaeaDIW5qVIO4TNXyetzogSl49nCztjxHgyJax+oEDXEkYcBb+KY+AGcA
tt2fNE/ko5XEMPJFDuIDmTSRl35m6pn5gL8kwfHhpk/ZL2q1EtjVV+Bj3ZhCe4LP
719QfgQnN8TCfHTI42MWdIZTq9RHZLv+QUtx+02r8U4JTByn6uoccOCfGHUa2pBD
4Mi/NRjeQudxu+uKLH/1fAKiPzDWSLytevdOha7KtFfo1DZSKVB8vfYgMDfAVDiT
VSdwcPFJUclLPvQGOEdwZY7g9q/WO98nuHpzjRrdmHpZ0Ms/ZzCNsG5qaFhS7A8Q
oAZPaA+3sRx3q/8u86oAVEyJqdbZtTpvX9Et4jth4gDk6HruLUgzZYk7Y2R1Spn9
mG0YqGdtCxDU5u0CMA6qWXeNNv8pNN4w7g6SVVYDU8v5W8nM+z/tm32NCkfcatwR
YkPMIOKj4hPuMJGSMzbs23ntG3ucRVwJU87d61SWyenHFvzLJvEPhDFGIPSvnzgL
1s8rxkHs7jbwhJFacA==
=Fvee
-END PGP SIGNATURE-

Adriaan de Groot (1):
  FindLua: Set CMP0012 to NEW for the revised search code

Andrew Fuller (1):
  CPack/Deb: Restore setting of root as the owner of files

Brad King (9):
  Merge branch 'policy_max_docs' into release-3.12
  Merge branch 'cpack-fix-deb-packaging' into release-3.12
  Revert "target_link_libraries: Allow use with targets in other 
directories"
  Merge branch 'backport-UseSWIG-legacy-targets' into release-3.12
  Merge branch 'FindLua-CMP0012' into release-3.12
  Merge branch 'revert-subdirectory-linking' into release-3.12
  Merge branch 'doc-add_compile_definitions' into release-3.12
  Merge branch 'csharp-link-file' into release-3.12
  CMake 3.12.0-rc3

Craig Scott (1):
  Help: Clarify ... behavior for policy-related commands

Marc Chevrier (2):
  UseSWIG: reintroduce legacy target name management
  Help: fix add_compile_definitions() documentation

Robert Dailey (1):
  VS: Only link cs files when they're not in binary dir

---


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] specifying path for license file for commercial compiler?

[Clune, Thomas L. (GSFC-6101)]

Mark and Juan,

Thanks!   Between your two suggestions I was able to make something work.My 
first attempt at using -DCMAKE_TOOLCHAIN_FILE resulted in some error messages 
that I completely misinterpreted as needing to “re-teach”  CMAKE about the 
Intel compiler.A simple wrapper for the compiler does exactly what was 
desired.





> On Jul 9, 2018, at 4:40 AM, Marc CHEVRIER  wrote:
> 
> You have just to put set command (not cache) for your compiler 
> (CMAKE_Fortran_COMPILER) and environment variable in a file and specify this 
> file on cmake command line with option -DCMAKE_TOOLCHAIN_FILE=your-file.



> On Jul 8, 2018, at 10:32 PM, Juan E. Sanchez  wrote:
> 
> Hi,
> 
> Could you create a simple compiler wrapper script, and point the 
> CMAKE_*_COMPILER variables there:
> 
> #!/bin/bash
> export INTEL_LICENSE_FILE=/usr/local/intel/license
> /path/to/ifort "$@"
> 
> Regards,
> 
> Juan
> 

-- 

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-commits] CMake branch, release, updated. v3.12.0-rc2-15-g7f1569d

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  7f1569d2d8c1a647cf4d1b0696834952cf8f00fb (commit)
  from  855dafdda090b182c966415b5fc2e0a515fbb701 (commit)

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

- Log -
---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.12.0-rc2-175-g1b5b1dc

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  1b5b1dc5cc5d1fd92fafcece3b4ae8ad51fd5817 (commit)
   via  7f1569d2d8c1a647cf4d1b0696834952cf8f00fb (commit)
  from  6c33f39c30f869ef78f33a0b3a05e286767929c7 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b5b1dc5cc5d1fd92fafcece3b4ae8ad51fd5817
commit 1b5b1dc5cc5d1fd92fafcece3b4ae8ad51fd5817
Merge: 6c33f39 7f1569d
Author: Brad King 
AuthorDate: Mon Jul 9 09:30:54 2018 -0400
Commit: Brad King 
CommitDate: Mon Jul 9 09:30:54 2018 -0400

Merge branch 'release-3.12'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [cmake-developers] why can target_include_directories() not be applied to custom targets?

[Attila Krasznahorkay]

Hi,

Just to say that setting INCLUDE_DIRECTORIES on a custom target is indeed a bit 
of an obscure thing, but we do use it. You can find the full reasoning in:

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

Because of that, I understood that CMake will provide this functionality in the 
future as well, so we can rely on this build setup.

Cheers,
  Attila

> On 8 Jul 2018, at 12:16, Petr Kmoch  wrote:
> 
> Hi Drew,
> 
> a custom target can do literally anything, it's just a buildsystem wrapper 
> for running arbitrary executables; or often not even that, and is just a 
> collection of custom commands. There is nothing CMake automatically does with 
> the properties [INTERFACE_]INCLUDE_DIRECTORIES set on a custom command.
> 
> Note that if you need the properties set for some reason (i.e. if your custom 
> command/target code uses them for something), you can still set them just 
> fine using set_property() or set_target_properties(). However, I expect this 
> to be a very rare thing to do, so I think it's OK 
> target_include_directories() actually errors out on custom targets. IMO it's 
> much more likely that a non-custom target was intended.
> 
> (Note that I am just an ordinary CMake user, so the above is in no way 
> "official.")
> 
> Petr
> 
> On 7 July 2018 at 21:27, Drew Parsons  wrote:
> Commit 510fdcb18801076e2041eaae2941375eecc93ec2 at
> https://gitlab.kitware.com/cmake/cmake/commit/510fdcb18801076e2041eaae2941375eecc93ec2
> prevents custom targets from using target_include_directories().
> 
> This makes no sense to me.  A custom target is still a target. It needs
> to be compiled, it uses -I flags.
> 
> Can you explain the ban on applying target_include_directories() to
> custom targets?
> 
> Drew
> 
> -- 
> 
> 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-developers
> 
> -- 
> 
> 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-developers

-- 

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

Re: [CMake] specifying path for license file for commercial compiler?

[Clune, Thomas L. (GSFC-6101)]

> On Jul 9, 2018, at 1:04 AM, Alan W. Irwin  wrote:
> 
> On 2018-07-06 20:34- Clune, Thomas L. (GSFC-6101) wrote:
> 
>> To use the Intel compiler, one must use an environment variable that 
>> specifies the path to the license file.  E.g.,
>> 
>>   export INTEL_LICENSE_FILE=/usr/local/intel/license
>> 
>> Other commercial compilers use a very similar mechanism.I had hoped to 
>> capture such information in a cache file so that I could avoid polluting the 
>> shell where I am invoking cmake:
>> 
>>   % cmake -C my-cache 
>> 
>> Such a cache file could  look like:
>> 
>>   set(CMAKE_Fortran_COMPILER 
>> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
>>  CACHE path "Fortran compiler")
>>   set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel 
>> license")
>> 
>> 
>> Unfortunately, the compiler is not “seeing” the env variable and complains 
>> that there is no license. Is there a solution to this, or am I forced to 
>> set the env variable each time I try to build?
> 
> Hi Thomas:
> 
> I only skimmed responses so someone else may have said this as well,
> but you will need a valid license both at cmake time (since cmake
> typically tests the compiler to see if it works) and also at build
> time when you obviously also have to use the compiler.  In both cases
> to answer your concern about polluting your normal environment
> variable setup, I would advocate simply setting the environment
> variable *just* for the command, e.g.,
> 
> env INTEL_LICENSE_FILE=/usr/local/intel/license cmake 
> env INTEL_LICENSE_FILE=/usr/local/intel/license make …

I agree that this will work, but I’m trying to make things as easy as possible 
on our “developers”.  (Our developers are largely scientists with little 
interest learning any new details about our build system, and I’m the one 
forcing them towards cmake.)   Currently _every_ other setting in the 
configuration is captured in the generated make system and their remains a 
danger that someone will login the next morning and forget to make the extra 
step.It really is not that big of a deal, but the difference is glaring 
given nothing else needs this.


> 
> rather than doing anything more complex.
> 
> I also have to ask is ifort really a necessity for you?  There are
> two reasons I have asked this question.
> 
> * Licensing infrastructure you need with proprietary compilers was
> just plain annoying to me in the past.  In the old days in a shared
> environment I often had to wait to get work done until a compiler
> license became available from someone else who was using it.  So our
> institution kept buying more licenses, but it was never enough.  

Our computing centers have what is in essence an unlimited license, so this is 
not an issue for us.   (Helps when you buy thousands of cores each year.)   

There are several issues here.We try to keep our model as portable as 
possible.   In practice this means gfortran, ifort, and PGI, with plans for 
others.   Intel remains the workhorse for the scientists because it generates 
faster code  (10%-25% depending on the configuration.)Any given version of 
the model is intended therefore to default to a specific version of the Intel 
compiler.   The core team needs the ability to explore variant versions of the 
compiler as we introduce new features that break older compilers.In theory, 
and aside from this license file issue,  all of the pertinent information can 
be set on the command line for cmake and then subsequent make commands are very 
simple ‘make install’. 

I’ve not yet exposed the scientists to the cmake build system, and they are 
still using a well-designed but idiosyncratic set of GNUmake + env setup 
scripts.   I would like to capture the details for the variant builds so that 
the typical scientist can simply type:

% cmake  
% make -j 10 install

while the core team can do variants with

% cmake
or
% cmake  

Currently I am using environment modules  (mod and lmod) to load the path for 
the compiler and license files.   This is workable, but I thought I could go 
one step further and eliminate the need for setting up an environment for the 
‘make’ step.


> And
> also in the old days when Sourceforge had a compile farm including
> licensed compilers from Sun, that licensing software was semi-broken
> and would often make it impossible to use the Sun part of the compile
> farm.  Maybe licensing infrastructure is much better implemented now,
> but those bad old days completely radicalized me about licensing
> infrastructure annoyances, and as a result I have been content for
> years to compile fortran code with gfortran which has no licensing
> infrastructure annoyances and virtually always produces reliable
> results for me.

While we technically do not have a mandate to support our compiler for external 
developers, we do maintain gfortran capabilities for various reasons including 
the ones you 

[Cmake-commits] CMake branch, release, updated. v3.12.0-rc2-14-g855dafd

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  855dafdda090b182c966415b5fc2e0a515fbb701 (commit)
   via  8a6107650e60b0ca2b9dfdad4b86d1b2f57bbfd7 (commit)
  from  0f3d7a1398f943b2417b317fa28c4a7cd5f7c6de (commit)

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

- Log -
---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.12.0-rc2-173-g6c33f39

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  6c33f39c30f869ef78f33a0b3a05e286767929c7 (commit)
   via  855dafdda090b182c966415b5fc2e0a515fbb701 (commit)
  from  ed75309344efe28eeb931fd537853ed8030db0a1 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c33f39c30f869ef78f33a0b3a05e286767929c7
commit 6c33f39c30f869ef78f33a0b3a05e286767929c7
Merge: ed75309 855dafd
Author: Brad King 
AuthorDate: Mon Jul 9 07:49:19 2018 -0400
Commit: Brad King 
CommitDate: Mon Jul 9 07:49:19 2018 -0400

Merge branch 'release-3.12'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.12.0-rc2-171-ged75309

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ed75309344efe28eeb931fd537853ed8030db0a1 (commit)
   via  8a6107650e60b0ca2b9dfdad4b86d1b2f57bbfd7 (commit)
  from  0100e5b2a73deedc4c82ad1925a2ab39d5d63960 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed75309344efe28eeb931fd537853ed8030db0a1
commit ed75309344efe28eeb931fd537853ed8030db0a1
Merge: 0100e5b 8a61076
Author: Brad King 
AuthorDate: Mon Jul 9 11:33:28 2018 +
Commit: Kitware Robot 
CommitDate: Mon Jul 9 07:33:35 2018 -0400

Merge topic 'csharp-link-file'

8a6107650e VS: Only link cs files when they're not in binary dir

Acked-by: Kitware Robot 
Acked-by: Michael Stürmer 
Merge-request: !2177


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a6107650e60b0ca2b9dfdad4b86d1b2f57bbfd7
commit 8a6107650e60b0ca2b9dfdad4b86d1b2f57bbfd7
Author: Robert Dailey 
AuthorDate: Fri Jun 29 15:30:59 2018 -0500
Commit: Brad King 
CommitDate: Fri Jul 6 09:45:15 2018 -0400

VS: Only link cs files when they're not in binary dir

When `*.cs` files are provided, do not generate a `` element in
the `.csproj` project if those files are descendants of
`CMAKE_CURRENT_BINARY_DIR`. This comparison happens for each file.

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index b9ec301..eff915b 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -4523,14 +4523,17 @@ void 
cmVisualStudio10TargetGenerator::WriteCSharpSourceProperties(
 void cmVisualStudio10TargetGenerator::GetCSharpSourceLink(
   cmSourceFile const* sf, std::string& link)
 {
-  std::string f = sf->GetFullPath();
-  if (!this->InSourceBuild) {
+  std::string const& sourceFilePath = sf->GetFullPath();
+  std::string const& binaryDir = LocalGenerator->GetCurrentBinaryDirectory();
+
+  if (!cmSystemTools::IsSubDirectory(sourceFilePath, binaryDir)) {
 const std::string stripFromPath =
   this->Makefile->GetCurrentSourceDirectory();
-if (f.find(stripFromPath) != std::string::npos) {
-  link = f.substr(stripFromPath.length() + 1);
+if (sourceFilePath.find(stripFromPath) == 0) {
   if (const char* l = sf->GetProperty("VS_CSHARP_Link")) {
 link = l;
+  } else {
+link = sourceFilePath.substr(stripFromPath.length() + 1);
   }
   ConvertToWindowsSlash(link);
 }

---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] specifying path for license file for commercial compiler?

[Marc CHEVRIER]

You have just to put set command (not cache) for your compiler
(CMAKE_Fortran_COMPILER) and environment variable in a file and specify
this file on cmake command line with option
-DCMAKE_TOOLCHAIN_FILE=your-file.

Le lun. 9 juil. 2018 à 03:32, Clune, Thomas L. (GSFC-6101) <
thomas.l.cl...@nasa.gov> a écrit :

> Marc,
>
>
>
> Thank you for the suggestion.  Unfortunately, I’m a bit confused by the
> documentation and not at all sure how to proceed.   Further help would be
> appreciated.
>
>
>
> In particular, I do not see how to capture the existing Fortran, C and CXX
> toolchains and then provide the minor extension of setting this one
> environment variable.   In fact, at the moment, I don’t even see a simple
> way to cut-and-paste the cmake built-in toolchains into a file to use as my
> baseline for extension.
>
>
>
> Am I correct in assuming that once the above issues are solved, then a
> simple line of the form
>
>
>
> set(ENV(INTEL_LICENSE_FILE) “…”)
>
>
>
> will then ensure that the compiler “sees” that env variable?   Or do I
> need to wrap the compiler in a script which just raises many more issues as
> I need my project to be able to build with many different versions of the
> Intel compiler.
>
>
>
> Thanks in advance,
>
>
>
>- Tom
>
>
>
>
>
> *From: *Marc CHEVRIER 
> *Date: *Saturday, July 7, 2018 at 1:49 AM
> *To: *"Clune, Thomas L. (GSFC-6101)" 
> *Cc: *CMake MailingList 
> *Subject: *Re: [CMake] specifying path for license file for commercial
> compiler?
>
>
>
> May be using a toolchain file is more appropriate. See
>
> https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
>
>
>
>
>
> Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <
> thomas.l.cl...@nasa.gov> a écrit :
>
> To use the Intel compiler, one must use an environment variable that
> specifies the path to the license file.  E.g.,
>
> export INTEL_LICENSE_FILE=/usr/local/intel/license
>
> Other commercial compilers use a very similar mechanism.I had hoped to
> capture such information in a cache file so that I could avoid polluting
> the shell where I am invoking cmake:
>
> % cmake -C my-cache 
>
> Such a cache file could  look like:
>
> set(CMAKE_Fortran_COMPILER
> "/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
> CACHE path "Fortran compiler")
> set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path
> "Intel license")
>
>
> Unfortunately, the compiler is not “seeing” the env variable and complains
> that there is no license. Is there a solution to this, or am I forced
> to set the env variable each time I try to build?
>
>
>
>
>
>
>
> --
>
> 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] find_package: keyword REQUIRED ignored

[Mark De Wit]

I thought that the find script itself was responsible for checking the required 
flag?

Our own find scripts do something along the lines of (note that we named ours 
sqlite, not sqlite3!)

if(NOT sqlite_FIND_QUIETLY)
  MESSAGE(STATUS "Looking for sqlite...")
endif()

…  look for package here

… if not found and required, signal fatal error:
  if(sqlite_FIND_REQUIRED)
message(FATAL_ERROR "Looking for sqlite... - Not found")
  endif()


From the CMake documentation on find_package:

When loading a find module or package configuration file find_package defines 
variables to provide information about the call arguments (and restores their 
original state before returning):
…
_FIND_REQUIRED
true if REQUIRED option was given
_FIND_QUIETLY
true if QUIET option was given

In Module mode the loaded find module is responsible to honor the request 
detailed by these variables; see the find module for details. In Config mode 
find_package handles REQUIRED, QUIET, and [version] options automatically

Mark

From: CMake  On Behalf Of Quaquaraquà
Sent: 08 July 2018 22:35
To: Cmake Mailing List 
Subject: [CMake] find_package: keyword REQUIRED ignored


Hi there,

I'm using a custom script [1] to look for the library sqlite3. However, the 
keyword "REQUIRED" (as quietly) is ignored by find_package. That is even if the 
library is not found, the script continues is processing:

// CMakeLists.txt

cmake_minimum_required(VERSION 3.10)

project(hello_world)

list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build-aux/")

find_package(SQLite3 REQUIRED)

// output:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../
-- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
-- Configuring done
-- Generating done
-- Build files have been written to: ...



Any idea what is wrong here?



[1] https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.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] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds

[Nils Gladitz]

On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin 
wrote:

> My parallel builds on my Linux OS (currently Debian Buster, but this
> also happened for Debian Jessie so this is a long-standing problem)
> have ascii null ('\0) characters inserted in the output while the
> corresponding non-parallel build does not have those extra characters.
>

I narrowed it down with Ninja which buffers command outputs in parallel
builds which makes it easier to match output to specific commands.
Alternatively I think CTest launchers might have helped with this too.
CMake uses them to redirect build command outputs to distinct files for
CTest submissions.

I see null bytes coming from the "cat test.error" in the script file
generated from
https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in

If this only shows up in parallel builds perhaps multiple processes are
reading/writing the same test.error file in parallel?
Haven't looked closer than that. You probably know better where to look
from there.

Nils
-- 

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] find_package: keyword REQUIRED ignored

[Rolf Eike Beer]

Am 2018-07-08 23:34, schrieb Quaquaraquà:

Hi there,

I'm using a custom script [1] to look for the library sqlite3.
However, the keyword "REQUIRED" (as quietly) is ignored by
find_package. That is even if the library is not found, the script
continues is processing:

// CMakeLists.txt

cmake_minimum_required(VERSION 3.10)project(hello_world)list(APPEND
CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/build-aux/")
find_package(SQLite3 REQUIRED)

// output:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++ -G "CodeBlocks - Unix Makefiles" ../
-- Could NOT find SQLITE3 (missing: SQLITE3_LIBRARY)
-- Configuring done
-- Generating done
-- Build files have been written to: ...


Any idea what is wrong here?


[1] 
https://github.com/LuaDist/libsqlite3/blob/master/cmake/FindSQLite3.cmake


Try:

find_package_handle_standard_args(SQLite3 …

i.e. use the same case for the prefix as your file is called. And maybe 
use the second function signature of FPHSA.


Greetings,

Eike
--
--

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] ENOEXEC exit code from ctest on FreeBSD

[Eric Noulard]

Le lun. 9 juil. 2018 à 07:14, Anoop C S  a écrit :

> Hi all,
>
> While running tests from a wip branch[1] for socket_wrapper project I
> noticed the following output
> on FreeBSD:
>
>
Your issue seems more related with the "socker wrapper" project than with
CMake/CTest but...


> Following that I ran one among the failed tests from the above list using
> `ctest`:
>
> # ctest -R test_thread_echo_tcp_connect
> Test project /root/build
> Start 21: test_thread_echo_tcp_connect
> 1/1 Test #21: test_thread_echo_tcp_connect .***Failed0.07 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =   0.07 sec
>
> The following tests FAILED:
>  21 - test_thread_echo_tcp_connect (Failed)
> Errors while running CTest
>

If you want to have more verbose output from ctest you an run:

ctest -R test_thread_echo_tcp_connect -VV

and ctest will spit out whatever output "test_thread_echo_tcp_connect" is
giving.
otherwise did you try to run the test "manually" without ctest:

from
https://git.cryptomilk.org/users/asn/socket_wrapper.git/tree/tests/CMakeLists.txt?h=master-fix
it looks like the test executable is:

test_thread_echo_tcp_connect

so try running:

./test_thread_echo_tcp_connect

and whether it fails or not.



> # uname -a
> FreeBSD bazinga.localdomain 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
> Fri Jul 21 02:08:28 UTC
> 2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>
>
You seem to be compiling and running your tests as 'root' user. This is
usually not a good idea
(even if it may not have anything to do with your failure).


> I couldn't see any genuine errors from the test logs as such. Am I missing
> something? Since I am a
> newbie to FreeBSD(and also to cmake) I would require some help to debug
> the reason for ENOEXEC exit
> code.
>

Try running in verbose mode, you may even debug into the test if you run
the test without ctest.


>
> Note:- The failed test cases uses threads.
> [1]
> https://git.cryptomilk.org/users/asn/socket_wrapper.git/log/?h=master-fix
>
>
Then I suggest you ask on the project mailing list what may make this test
fail.

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