[Cmake-commits] CMake branch, master, updated. v3.9.2-826-gdb86cf4

[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  db86cf4e7ebc3a3cb9bf29d2d39986601e6edf90 (commit)
  from  c0c5f924fe46fcf83603117689b372cb8520c4bb (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=db86cf4e7ebc3a3cb9bf29d2d39986601e6edf90
commit db86cf4e7ebc3a3cb9bf29d2d39986601e6edf90
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Sep 16 00:01:03 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Sep 16 00:01:03 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 8ba34f2..3539302 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 9)
-set(CMake_VERSION_PATCH 20170915)
+set(CMake_VERSION_PATCH 20170916)
 #set(CMake_VERSION_RC 1)

---

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


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

[CMake] FW: Visual Studio 2017

[Thompson, KT]

Randy,

Miroslav's recommendation should work. To expand on his response, here are the 
commands that I use with VS2017 to allow cmake to run from the command line:

- Start cmd session (should also work via powershell)
- To import VS17's command line environment run "C:\Program Files 
(x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" 
x86 
- Add extra project specific environment variables (possibly including 
appending PATH with the location of cmake).

I created a batch file that does these steps for me (and a shortcut on my 
desktop that runs the batch file).

@echo off
rem cmake-with-vs17-env.bat
@call "C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %*
set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program 
Files\doxygen\bin;c:\Python27amd64
rem set CMAKE_PREFIX_PATH=

With this environment, I can run cmake from the command line (cmake-gui or 
cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and 
I can build them with or w/o the GUI.

I hope this helps!

-kt


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Mateju Miroslav, Ing.
Sent: Friday, September 15, 2017 6:15 AM
To: Randy Heiland ; cmake@cmake.org
Subject: Re: [CMake] Visual Studio 2017

Hello Randy,

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Randy Heiland
Sent: Friday, September 15, 2017 1:38 PM

> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? 
> And by "best", I mean with minimal effort on users.
> To be more specific, on Windows, I *think* I'd like to have users install the 
> cmake binary, then use Powershell to build an application.
Is there really a need for using PowerShell if you also want to use the same 
CMakeLists for Linux?

> But my initial attempt to do so is confusing. I install VS17 (for C++), it 
> installs in standard path, but 'cl' is not found in Powershell. I read that I 
> shouldn't edit my PATH (nor do I really want users to have to), but run some 
> .bat instead to setup my env. So, how should one specify the compiler for 
> cmake? Oh yes, then I see that VS17 also has its own cmake??


Have you run CMake successfully yet? I am not really aware how it works but 
CMake *can* for sure detect VS in my CLI environment without having VS in PATH. 
If you use an IDE that understands CMake (like VS17 or Qt Creator, for 
example), you should be able to open a CMake project in the IDE and build it 
there. Please report your particular problem if it does not work for you.
If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are 
looking for.

Best regards,

Ing. Miroslav Matějů
Programmer Analyst

AŽD Praha s.r.o.
Technology Division
Research and Development
Žirovnická 2/3146, 106 17  Prague
Czech Republic
Phone: +420 267 287 476
Web: www.azd.cz
-- 

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] SWIG CMAKE project not linked correctly

[Bruce Jones]

I'm not sure what is different between the CMake generated build and the
manual build, but according to the swig community definitions in the cpp
should be fine. I also couldn't find anything in the swig documentation to
suggest otherwise.

I did originally raise an issue on the swig github page:
https://github.com/swig/swig/issues/1091#issuecomment-329606916


On Fri, 15 Sep 2017 at 12:33 Hendrik Sattler 
wrote:

>
>
> Am 15. September 2017 15:23:42 MESZ schrieb Bruce Jones <
> bruce.david.jo...@gmail.com>:
> >Hi,
> >
> >I have a relatively simple SWIG - CMAKE project that is not linked
> >correctly, source files can be downloaded here:
> >https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ
> >
> >The problem I have is if the template function Foo is implemented in
> >the
> >header file, the project compiles and works successfully. If Foo is
> >instead
> >implemented in the cpp file, the project compiles but fails either when
> >linking on at runtime on Windows and Linux respectively.
>
> Templated member functions must be defined in the header. Exceptions are
> explicitly instantiated ones for certain template parameter values.
>
> >On windows the build will fail at linking with "unresolved external
> >symbols", as though the template function is not instantiated.
> >
> >On Linux python fails to import the module with "undefined symbol".
> >
> >If I build the projects by hand (not with CMake) they compile and link
> >successfully, and run successfully.
>
> Strange. it should not work because the method definition in the cpp file
> will not result in any symbol due to unknown type T. So what are you doing
> differently? Some commands must differ.
>
> HS
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
-- 

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] SWIG CMAKE project not linked correctly

[Hendrik Sattler]

Am 15. September 2017 15:23:42 MESZ schrieb Bruce Jones 
:
>Hi,
>
>I have a relatively simple SWIG - CMAKE project that is not linked
>correctly, source files can be downloaded here:
>https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ
>
>The problem I have is if the template function Foo is implemented in
>the
>header file, the project compiles and works successfully. If Foo is
>instead
>implemented in the cpp file, the project compiles but fails either when
>linking on at runtime on Windows and Linux respectively.

Templated member functions must be defined in the header. Exceptions are 
explicitly instantiated ones for certain template parameter values.

>On windows the build will fail at linking with "unresolved external
>symbols", as though the template function is not instantiated.
>
>On Linux python fails to import the module with "undefined symbol".
>
>If I build the projects by hand (not with CMake) they compile and link
>successfully, and run successfully.

Strange. it should not work because the method definition in the cpp file will 
not result in any symbol due to unknown type T. So what are you doing 
differently? Some commands must differ.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Sure.. but I haven't even thought about it much yet.  So when that has
happened, I'll make a more formal proposal.

Thanks,
Steven

On Fri, Sep 15, 2017 at 11:04 AM, Brad King  wrote:

> On 09/15/2017 10:55 AM, Steven Velez wrote:
> > I am assuming that the lack of response indicates that there has not
> > been much thought or interest expressed along this dimension of the
> feature.
> >
> > Would a better way to approach this be to implement a prototype and
> create a WIP MR?
>
> Can you post a more specific proposal here?  E.g. with proposed
> target properties to control it and show some examples.
>
> Thanks,
> -Brad
>
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extending XCode scheme generation support

[Brad King]

On 09/15/2017 10:55 AM, Steven Velez wrote:
> I am assuming that the lack of response indicates that there has not
> been much thought or interest expressed along this dimension of the feature.
> 
> Would a better way to approach this be to implement a prototype and create a 
> WIP MR?

Can you post a more specific proposal here?  E.g. with proposed
target properties to control it and show some examples.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Extending XCode scheme generation support

[Steven Velez]

Hello,

I am assuming that the lack of response indicates that there has not been
much thought or interest expressed along this dimension of the feature.

Would a better way to approach this be to implement a prototype and create
a WIP MR?

Thanks,
Steven


On Fri, Sep 8, 2017 at 12:29 PM, Steven Velez  wrote:

> Hello All,
>
> I recently noticed that 3.9.1 added the ability for the XCode generator to
> also generate scheme files.  This is great as we have been post processing
> generator output to add schemes according to our standards, but are
> discovering various issues with this approach.
>
> However, the current scheme generation appears to lack a couple of
> abilities we would require to replace our custom scripts.  Primarily, we
> need more flexibility over what goes in a particular scheme's launch
> configuration.
>
> I have searched the lists and google to try to find discussions on the
> intended direction of this feature, but could not find any.
>
> If I were to be able to contribute to this, would there be some sort of
> guidance available around how best to expose additional configurability to
> a user?  My immediate thoughts are just that we would need to define/use
> additional target properties, but is there any sort of recommended naming
> convention/scheme or structure that is already existing for mapping sets of
> properties in to the more structured format of scheme xml files.
>
> Thanks,
> Steven
>
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] SWIG CMAKE project not linked correctly

[Bruce Jones]

Hi,

I have a relatively simple SWIG - CMAKE project that is not linked
correctly, source files can be downloaded here:
https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ

The problem I have is if the template function Foo is implemented in the
header file, the project compiles and works successfully. If Foo is instead
implemented in the cpp file, the project compiles but fails either when
linking on at runtime on Windows and Linux respectively.

On windows the build will fail at linking with "unresolved external
symbols", as though the template function is not instantiated.

On Linux python fails to import the module with "undefined symbol".

If I build the projects by hand (not with CMake) they compile and link
successfully, and run successfully.

Any suggestions?

Cheers,
Bruce
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/15/2017 8:22 AM, Brad King wrote:

On 09/14/2017 11:33 PM, Edward Diener wrote:

Boost Build has tests for running an application successfully or not,
for compiling one or more source files successfully or not, and for
building one or more source files into an exe or not. These tests in
Boost Build are the run/run-fail, compile/compile-fail, and
link/link-fail rules.


Good summary.  One major difference is that Boost Build directly controls
the entire build graph and is natively aware of expected failure cases.
CMake needs to generate an external build system e.g. as Visual Studio
`.vcxproj` files with no good way to represent expected failure directly.
This is a technical reason CMake has never gained this functionality,
but perhaps it could be overcome with a careful design.  See below.


I am a relative beginner with CMake although pretty knowledgeable about 
Boost Build and Visual Studio, so please take my comments based on those 
criteria. A gui environment like Visual Studio does provide 
functionality to just compile one or more source files, and it also 
provides functionality to just build an executable from one or more 
source files without actually running that executable. I do not know how 
CMake "picks up" the results of its add_test when the build engine is 
Visual Studio, but however it does so it seems it could also "pick up" 
the result of a compile or of a compile/link in Visual Studio also, 
although I do not know how difficult this would be to do.





CMake/CTest has the exact equivalent to the run/run-fail rule in its
add_test framework


While `add_test` can do run/run-fail it doesn't do so given just a
source file like Boost Build does.  `add_test` expects to be given a
command referring to some executable that already exists or is built
elsewhere in the project via `add_executable`.  Therefore some work
would be needed even to reproduce Boost's run/run-fail infrastructure.


Boost Build's version of 'run/run-fail' does build an executable from 
the source file(s) that are part of its 'run/run-fail' rule. Giving a 
target name for that executable is optional, else the target name is 
taken from the first source file mentioned. I am not asking that CMake's 
'add_test' completely duplicate Boost Build's 'run/run-fail' rules and I 
do not mind the way that CMake works using an 'add_executable' as long 
as the 'add_executable' for testing can be turned off as a normal build 
target. In general I am not asking that CMake completely duplicate 
exactly Boost Build in these testing scenarios, but that it offer 
similar functionality so that the basic functionality of the Boost Build 
'run', 'compile', and 'link' rules have a CMake equivalent. I think the 
current 'add_executable', 'add_test' is a good enough equivalent to 
Boost Build's 'run/run-fail' rule. I would just like to see a built-in 
equivalent to testing under CMake which involves only a successful 
compilation or not, equivalent to Boost Build's 'compile/compile-fail' 
rule and a built-in equivalent to testing which involves only a 
successful build or not of a non-build target equivalent to Boost 
Build's 'link/link-fail' rule. I think both of the latter are valid 
testing methodologies which do not involve an actual run-time test.





Hopefully CMake developers will get the message and make the necessary
update to CMake/CTest.


We understand the value of the tests but simply don't have the need for
them in our own use cases.  This is a non-technical reason CMake does
not have this functionality, but it doesn't stand in the way of others
contributing a solution.


Who are "we" in your previous paragraph ? I believe that you as a 
developer understand that compile-time testing is a reality in the C++ 
world of programming, although I am not sure what other computer 
languages CMake supports and if compile-time testing exists in those 
other languages. Outside of Boost, which pushes the bounds of C++ 
library development and for whom, due to Boost's basis of heavily 
relying on template programming, and where compile-time testing has long 
been a reality, other C++ programmers have occasionally mentioned a need 
for compile-time testing under CMake to be added to CMake's run-time 
testing infrastructure. I am just suggesting that this should not be a 
popularity contest but just a recognition that compile-time testing 
should be supported by CMake within the same generally testing framework 
in which CMake supports run-time testing.


I freely admit that I am a basically a CMake beginner even as an 
end-user, and certainly not a CMake developer and do not know what 
adding compile-time testing would entail at the CMake developer level. 
But as a Boost library contributor, who has designed compile-time tests 
for my own supported libraries in Boost, and who has seen compile-time 
tests for many other Boost libraries, the fact that Boost Build contains 
support for compile-time testing and CMake does not is disconcerting 

[Cmake-commits] CMake branch, master, updated. v3.9.2-813-gead879d

[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  ead879df2067ccada6cc86ed6248bff850f0f6ec (commit)
   via  5dc215e03b6a7a421cd024daa8e8747d46b9e60d (commit)
   via  a8f70b32fbe11dab75580f1310c47a42dae59779 (commit)
   via  549366cbfc425cdeb3b84e78ea2f0ca3010c8a2a (commit)
  from  6b76615c4e55dc93fbe6880151a4a24ae700987b (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=ead879df2067ccada6cc86ed6248bff850f0f6ec
commit ead879df2067ccada6cc86ed6248bff850f0f6ec
Merge: 6b76615 5dc215e
Author: Brad King 
AuthorDate: Fri Sep 15 12:41:58 2017 +
Commit: Kitware Robot 
CommitDate: Fri Sep 15 08:42:16 2017 -0400

Merge topic 'fphsa-fix-version-exact'

5dc215e0 FPHSA: fix typo in comment
a8f70b32 FPHSA: replace left-over VERSION by _FOUND_VERSION.
549366cb FPHSA: Add (failing) unit test when checking EXACT on full version 
number

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5dc215e03b6a7a421cd024daa8e8747d46b9e60d
commit 5dc215e03b6a7a421cd024daa8e8747d46b9e60d
Author: Yves Frederix 
AuthorDate: Wed Sep 13 23:00:26 2017 +0200
Commit: Brad King 
CommitDate: Thu Sep 14 08:21:38 2017 -0400

FPHSA: fix typo in comment

diff --git a/Tests/RunCMake/FPHSA/RunCMakeTest.cmake 
b/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
index 2ac309b..dd73cd4 100644
--- a/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
+++ b/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
@@ -9,12 +9,12 @@ run_cmake(BadFoundVar)
 set(RunCMake_TEST_OPTIONS "-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_LIST_DIR}" 
"-DPseudo_VERSION=0")
 run_cmake(any_version_find_0)
 
-# Find a package with more customary version number, without requestion a 
specific version and in
+# Find a package with more customary version number, without requesting a 
specific version and in
 # the presence of a cache variable VERSION.
 set(RunCMake_TEST_OPTIONS "-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_LIST_DIR}" 
"-DPseudoNoVersionVar_VERSION=1.2.3.4_SHOULD_BE_IGNORED" 
"-DVERSION=BAD_VERSION")
 run_cmake(any_version_VERSION_cache_variable)
 
-# Find a package with a more customary version number, without requestion a 
specific version.
+# Find a package with a more customary version number, without requesting a 
specific version.
 set(RunCMake_TEST_OPTIONS "-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_LIST_DIR}" 
"-DPseudo_VERSION=1.2.3.4")
 run_cmake(any_version)
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8f70b32fbe11dab75580f1310c47a42dae59779
commit a8f70b32fbe11dab75580f1310c47a42dae59779
Author: Yves Frederix 
AuthorDate: Wed Sep 13 21:10:46 2017 +0200
Commit: Brad King 
CommitDate: Thu Sep 14 08:21:38 2017 -0400

FPHSA: replace left-over VERSION by _FOUND_VERSION.

This was accidentally left out of commit aec27c152e (FPHSA: use more
localized _FOUND_VERSION instead of VERSION, 2017-09-05).

Fixes: #17281

diff --git a/Modules/FindPackageHandleStandardArgs.cmake 
b/Modules/FindPackageHandleStandardArgs.cmake
index 7b08bea..67f6bd6 100644
--- a/Modules/FindPackageHandleStandardArgs.cmake
+++ b/Modules/FindPackageHandleStandardArgs.cmake
@@ -322,7 +322,7 @@ function(FIND_PACKAGE_HANDLE_STANDARD_ARGS _NAME _FIRST_ARG)
   endif ()
   unset(_VERSION_HEAD)
 else ()
-  if (NOT ${_NAME}_FIND_VERSION VERSION_EQUAL VERSION)
+  if (NOT ${_NAME}_FIND_VERSION VERSION_EQUAL _FOUND_VERSION)
 set(VERSION_MSG "Found unsuitable version \"${_FOUND_VERSION}\", 
but required is exact version \"${${_NAME}_FIND_VERSION}\"")
 set(VERSION_OK FALSE)
   else ()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=549366cbfc425cdeb3b84e78ea2f0ca3010c8a2a
commit 549366cbfc425cdeb3b84e78ea2f0ca3010c8a2a
Author: Yves Frederix 
AuthorDate: Wed Sep 13 21:56:25 2017 +0200
Commit: Brad King 
CommitDate: Thu Sep 14 08:21:22 2017 -0400

FPHSA: Add (failing) unit test when checking EXACT on full version number

This test detects a regression introduced by commit aec27c152e (FPHSA:
use more localized _FOUND_VERSION instead of VERSION, 2017-09-05).

diff --git a/Tests/RunCMake/FPHSA/RunCMakeTest.cmake 
b/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
index 1b71a31..2ac309b 100644
--- a/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
+++ b/Tests/RunCMake/FPHSA/RunCMakeTest.cmake
@@ 

Re: [cmake-developers] Adding compile and build type tests to CMake/CTest

[Brad King]

On 09/14/2017 11:33 PM, Edward Diener wrote:
> Boost Build has tests for running an application successfully or not, 
> for compiling one or more source files successfully or not, and for 
> building one or more source files into an exe or not. These tests in 
> Boost Build are the run/run-fail, compile/compile-fail, and 
> link/link-fail rules.

Good summary.  One major difference is that Boost Build directly controls
the entire build graph and is natively aware of expected failure cases.
CMake needs to generate an external build system e.g. as Visual Studio
`.vcxproj` files with no good way to represent expected failure directly.
This is a technical reason CMake has never gained this functionality,
but perhaps it could be overcome with a careful design.  See below.

> CMake/CTest has the exact equivalent to the run/run-fail rule in its 
> add_test framework

While `add_test` can do run/run-fail it doesn't do so given just a
source file like Boost Build does.  `add_test` expects to be given a
command referring to some executable that already exists or is built
elsewhere in the project via `add_executable`.  Therefore some work
would be needed even to reproduce Boost's run/run-fail infrastructure.

> Hopefully CMake developers will get the message and make the necessary 
> update to CMake/CTest.

We understand the value of the tests but simply don't have the need for
them in our own use cases.  This is a non-technical reason CMake does
not have this functionality, but it doesn't stand in the way of others
contributing a solution.

> Is there any consensus that these other two types of tests might be 
> valuable for CMake/CTest, or any way to make this happen ?

I agree they would be useful.

>From some quick brainstorming, one idea to deal with the technical
challenge raised above is to add a new "BUILD_TEST" target property
to tell CMake that a target is meant only to be built during testing.
We allow dependencies among BUILD_TEST targets on each other and on
normal targets, but not from normal targets to BUILD_TEST targets.
That will give a separable part of the build graph to generate only
for testing.  Then add_test can create tests that try to build one
of the BUILD_TEST targets and expect one of the compile/compile-fail,
link/link-fail, or run/run-fail cases.

For generators like Visual Studio we could lave the BUILD_TEST
targets out of the main `.sln` file so they wouldn't show up when
users load the projects.  Instead they would be placed in a second
`.sln` file used only for testing.

Further design work is likely needed but this is a start.

-

IMO it will be better to first prototype this externally to gain some
experience with it and work with existing CMake releases.  One can do
this by using the `export()` command to make all targets in the build
tree available to externally-built projects (which is useful on its own).
With that a few approaches can be used to drive testing as an external
build.

Then have a custom target that configures the test-only part of the
project externally but doesn't build it.  The test-only project is
externally-built and can load the targets file created by `export()`
above.  Then use `add_test` to create tests that drive the build on
parts of the external test-only project and check for appropriate
success/failure and output matching.

-Brad
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Visual Studio 2017

[Matějů Miroslav , Ing .]

Hello Randy,

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Randy Heiland
Sent: Friday, September 15, 2017 1:38 PM

> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? 
> And by "best", I mean with minimal effort on users.
> To be more specific, on Windows, I *think* I'd like to have users install the 
> cmake binary, then use Powershell to build an application.
Is there really a need for using PowerShell if you also want to use the same 
CMakeLists for Linux?

> But my initial attempt to do so is confusing. I install VS17 (for C++), it 
> installs in standard path, but 'cl' is not found in Powershell. I read that I 
> shouldn't edit my PATH (nor do I really want users to have to), but run some 
> .bat instead to setup my env. So, how should one specify the compiler for 
> cmake? Oh yes, then I see that VS17 also has its own cmake??
Have you run CMake successfully yet? I am not really aware how it works but 
CMake *can* for sure detect VS in my CLI environment without having VS in PATH. 
If you use an IDE that understands CMake (like VS17 or Qt Creator, for 
example), you should be able to open a CMake project in the IDE and build it 
there. Please report your particular problem if it does not work for you.
If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are 
looking for.

Best regards,

Ing. Miroslav Matějů
Programmer Analyst

AŽD Praha s.r.o.
Technology Division
Research and Development
Žirovnická 2/3146, 106 17  Prague
Czech Republic
Phone: +420 267 287 476
Web: www.azd.cz
-- 

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] setting/removing compiler flag (-g) for a single project directory

[René J . V . Bertin]

Hi,

Is it possible to  set and/or remove compiler arguments on a project 
subdirectory that holds a tree with sources of a considerable number of build 
targets?

An example to make this more concrete: I have a project that contains

common_libs
plugins/foo
plugins/this_one

I'm just interested in building plugins/this_one and can do so by calling make 
&& make install/fast inside the build/plugins/this_one directory. All plugin 
dependencies are already installed (with debug info). The build/common_libs 
directory gets pretty big and is expensive to build, so ideally I would build 
everything in there with different flags, basically replacing -O3|-O2 with -Os 
and removing the -g option, possibly even running a strip before continuing the 
rest of the build.

I know one can do this kind of thing per target or even per file, but how does 
one do it on a directory basis? Do I have to cache the original CMAKE_C*_FLAGS 
value before modifying it in common_libs/CMakeLists.txt , and restore it before 
returning from that file? Or is there a more elegant method?

Thanks,
René
-- 

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-developers] Adding compile and build type tests to CMake/CTest

[Edward Diener]

I posted these messages to the users list but Bill Hoffman suggested I 
post them to the developers list:


Boost Build has tests for running an application successfully or not, 
for compiling one or more source files successfully or not, and for 
building one or more source files into an exe or not. These tests in 
Boost Build are the run/run-fail, compile/compile-fail, and 
link/link-fail rules.


CMake/CTest has the exact equivalent to the run/run-fail rule in its 
add_test framework, but there is not add_test equivalent to the other 
two sets of rules. It sure would be nice, when Boost transitions to 
using CMake/CTest instead of Boost Build, if CMake/CTest had the 
equivalent of the other two sets of types of test in its add_test framework.


To put it succinctly CMake should adding compile-time testing so that 
when some compilation succeeds the test is successful and if the 
compilation fails the test is not successful, with the proviso that you 
can reverse the result as a compile should fail type of test. Similarly 
a build type testing, without having to run anything should be added 
along the same lines.


In modern C++ it is perfectly feasible, especially with template 
programming, to do compile time testing, invoking a compile-time static 
assert as a compile-time failure. Boost has had this for years and 
modern C++ has it as part of the latest version of the C++ standard. 
CMake needs to update itself to the reality that pure compile-time 
testing is a reality for modern C++ and should update itself 
accordingly. Only having run-time testing is an artifact of the past. 
Hopefully CMake developers will get the message and make the necessary 
update to CMake/CTest.


Is there any consensus that these other two types of tests might be 
valuable for CMake/CTest, or any way to make this happen ?


--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] Visual Studio 2017

[Randy Heiland]

Hello,

I've googled "site:cmake.org/pipermail/cmake visual studio 2017" looking
for answers, but still confused, so thought I'd ask this list.
Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)?
And by "best", I mean with minimal effort on users. To be more specific, on
Windows, I *think* I'd like to have users install the cmake binary, then
use Powershell to build an application. But my initial attempt to do so is
confusing. I install VS17 (for C++), it installs in standard path, but 'cl'
is not found in Powershell. I read that I shouldn't edit my PATH (nor do I
really want users to have to), but run some .bat instead to setup my env.
So, how should one specify the compiler for cmake? Oh yes, then I see that
VS17 also has its own cmake??

I'd welcome suggestions.  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:
http://public.kitware.com/mailman/listinfo/cmake