[Cmake-commits] CMake branch, master, updated. v3.5.1-337-g00e4d12

[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  00e4d1220bb9f3c43bd3d339b0114d2074480bd7 (commit)
  from  90f24f016e93d18f6a244b39fd21c68355bdbe48 (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=00e4d1220bb9f3c43bd3d339b0114d2074480bd7
commit 00e4d1220bb9f3c43bd3d339b0114d2074480bd7
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Mar 30 00:01:06 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Mar 30 00:01:06 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6235b66..ea1d786 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 5)
-set(CMake_VERSION_PATCH 20160329)
+set(CMake_VERSION_PATCH 20160330)
 #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

Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Bill Hoffman]

On 3/29/2016 5:34 PM, Alan W. Irwin wrote:

In any case, whatever the issue is, Arjen appears (so far) to have
found a reliable reproducer with the -j option for ctest.  So I hope
others here try the -j option for ctest on MinGW-w64/MSYS2 platforms
for their favorite projects to get a better idea of how widespread
this issue is.
I would recommend building ctest with debug.  Then running it with -j 
and then use gdb to figure out where it is stuck.   Until we know 
exactly where it is stuck, the rest is pure speculation


-Bill


--

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] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Nils Gladitz]

On 29.03.2016 23:34, Alan W. Irwin wrote:

On 2016-03-29 22:46+0200 Nils Gladitz wrote:


On 29.03.2016 21:39, Alan W. Irwin wrote:

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?


Afair there are sporadic issues with the cygwin runtime (on which 
msys/msys2 is based) in the process handling code of kwsys (used by 
cmake).
The code is used by e.g. execute_process() and also ctest for test 
execution.


I think the issue is due to how pipes are implemented by the runtime.
From what I remember rsync also suffers from this.

Also having Kaspersky installed (even when paused) seems to make 
these hangs more likely.


Thanks, Nils, for that information.  Could this issue be related to
the Cygwin unreliability mentioned in
 where they say "In
summary, current Windows implementations make it impossible to
implement a perfectly reliable fork, and occasional fork failures are
inevitable."?


Afair the issue was a wait or select on the pipes used to connect to the 
spawned process rather than fork but I haven't debugged into it myself.
I think there was a cygwin mailing list post on this too but I don't 
seem to be able to find it.


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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Alan W. Irwin]

On 2016-03-29 22:46+0200 Nils Gladitz wrote:


On 29.03.2016 21:39, Alan W. Irwin wrote:

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?


Afair there are sporadic issues with the cygwin runtime (on which msys/msys2 
is based) in the process handling code of kwsys (used by cmake).

The code is used by e.g. execute_process() and also ctest for test execution.

I think the issue is due to how pipes are implemented by the runtime.
From what I remember rsync also suffers from this.

Also having Kaspersky installed (even when paused) seems to make these hangs 
more likely.


Thanks, Nils, for that information.  Could this issue be related to
the Cygwin unreliability mentioned in
 where they say "In
summary, current Windows implementations make it impossible to
implement a perfectly reliable fork, and occasional fork failures are
inevitable."?

In any case, whatever the issue is, Arjen appears (so far) to have
found a reliable reproducer with the -j option for ctest.  So I hope
others here try the -j option for ctest on MinGW-w64/MSYS2 platforms
for their favorite projects to get a better idea of how widespread
this issue is.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Nils Gladitz]

On 29.03.2016 21:39, Alan W. Irwin wrote:

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?


Afair there are sporadic issues with the cygwin runtime (on which 
msys/msys2 is based) in the process handling code of kwsys (used by cmake).
The code is used by e.g. execute_process() and also ctest for test 
execution.


I think the issue is due to how pipes are implemented by the runtime.
From what I remember rsync also suffers from this.

Also having Kaspersky installed (even when paused) seems to make these 
hangs more likely.


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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Alan W. Irwin]

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?

Previously, Arjen had discovered that the parallel build -j4 option
for make.exe (from the msys/make 4.1-4 package) was not reliable on
this platform.  I have forgotten all the details for that issue, but
we didn't pursue it further at that time because Cygwin also had the
same parallel make trouble so we wrote it off to some make.exe bug for
Cygwin that had been copied to MinGW-w64/MSYS2 platform (since the two
platforms are so closely related).

Of course, it always possible on both platforms that some make race
condition caused by a badly implemented CMake-based build system for
PLplot could be the source of these parallel make issues.  However,
make -j4 works fine for the Linux case so if there is such a make race
issue it is a subtle one. To eliminate this possibility does there
exist a definitive way to search for make race conditions for
CMake-based builds?  (I am thinking along the lines of looking for
duplicate "Building ..." lines in the output from "make all", but
there may be some better method that someone here would like to
suggest.)

Assuming make race conditions can be eliminated as the cause of the
issue with the make parallel build option, is there any obvious
connection between that issue and the parallel ctest issue on this
platform? For example, is the ctest parallel build option implemented
using generator facilities (e.g., the parallel build option for
make.exe) or do both the ctest and make implementations of their
respective parallel options use some common library that could be
screwing up on the MinGW-w64/MSYS2 platform?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v3.5.1-700-g24d3220

[Brad King]

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, next has been updated
   via  24d322015972bac129ee752fb45edc485fb17a45 (commit)
   via  49e82c15d57db01a95f740f511715064a3887615 (commit)
  from  9f8eac83accc640e3c88bcf36265e1028aa48b5d (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=24d322015972bac129ee752fb45edc485fb17a45
commit 24d322015972bac129ee752fb45edc485fb17a45
Merge: 9f8eac8 49e82c1
Author: Brad King 
AuthorDate: Tue Mar 29 14:36:20 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 14:36:20 2016 -0400

Merge topic 'fix-spelling-typos' into next

49e82c15 Fix spelling typos in comments and documentation (#16037)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49e82c15d57db01a95f740f511715064a3887615
commit 49e82c15d57db01a95f740f511715064a3887615
Author: Felix Geyer 
AuthorDate: Tue Mar 29 14:24:20 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 14:31:02 2016 -0400

Fix spelling typos in comments and documentation (#16037)

The Debian package checker tool (lintian) detected several typos in
CMake.

diff --git a/Help/command/add_executable.rst b/Help/command/add_executable.rst
index 8b3fb57..19ca658 100644
--- a/Help/command/add_executable.rst
+++ b/Help/command/add_executable.rst
@@ -73,7 +73,7 @@ does not appear in the generated buildsystem as a make 
target.  The
  may not be an :ref:`Imported Target ` or an
 ``ALIAS``.  ``ALIAS`` targets can be used as targets to read properties
 from, executables for custom commands and custom targets.  They can also be
-tested for existance with the regular :command:`if(TARGET)` subcommand.
+tested for existence with the regular :command:`if(TARGET)` subcommand.
 The  may not be used to modify properties of , that
 is, it may not be used as the operand of :command:`set_property`,
 :command:`set_target_properties`, :command:`target_link_libraries` etc.
diff --git a/Help/command/add_library.rst b/Help/command/add_library.rst
index 5033e18..36adcbe 100644
--- a/Help/command/add_library.rst
+++ b/Help/command/add_library.rst
@@ -123,7 +123,7 @@ used to refer to  in subsequent commands.  The 
 does
 not appear in the generatedbuildsystem as a make target.  The 
 may not be an :ref:`Imported Target ` or an ``ALIAS``.
 ``ALIAS`` targets can be used as linkable targets and as targets to
-read properties from.  They can also be tested for existance with the
+read properties from.  They can also be tested for existence with the
 regular :command:`if(TARGET)` subcommand.  The  may not be used
 to modify properties of , that is, it may not be used as the
 operand of :command:`set_property`, :command:`set_target_properties`,
diff --git a/Help/manual/cmake-buildsystem.7.rst 
b/Help/manual/cmake-buildsystem.7.rst
index 9004bb2..07bf33f 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -150,7 +150,7 @@ and :prop_tgt:`INTERFACE_COMPILE_OPTIONS` target properties.
 Each of the commands has a ``PRIVATE``, ``PUBLIC`` and ``INTERFACE`` mode.  The
 ``PRIVATE`` mode populates only the non-``INTERFACE_`` variant of the target
 property and the ``INTERFACE`` mode populates only the ``INTERFACE_`` variants.
-The ``PUBLIC`` mode populates both variants of the repective target property.
+The ``PUBLIC`` mode populates both variants of the respective target property.
 Each command may be invoked with multiple uses of each keyword:
 
 .. code-block:: cmake
diff --git a/Help/manual/cmake-generator-expressions.7.rst 
b/Help/manual/cmake-generator-expressions.7.rst
index 13ee4bd..d4f47dd 100644
--- a/Help/manual/cmake-generator-expressions.7.rst
+++ b/Help/manual/cmake-generator-expressions.7.rst
@@ -225,7 +225,7 @@ comparison::
   -I$
 
 generates a string of the entries in the :prop_tgt:`INCLUDE_DIRECTORIES` target
-property with each entry preceeded by ``-I``. Note that a more-complete use
+property with each entry preceded by ``-I``. Note that a more-complete use
 in this situation would require first checking if the INCLUDE_DIRECTORIES
 property is non-empty::
 
diff --git a/Help/manual/cmake-packages.7.rst b/Help/manual/cmake-packages.7.rst
index aebc5d9..c27c612 100644
--- a/Help/manual/cmake-packages.7.rst
+++ b/Help/manual/cmake-packages.7.rst
@@ -645,7 +645,7 @@ Disabling the Package Registry
 --
 
 In some cases using the Package Registries is not desirable. CMake
-allows to disable them using the following variables:
+allows one to disable 

[Cmake-commits] CMake branch, next, updated. v3.5.1-698-g9f8eac8

[Brad King]

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, next has been updated
   via  9f8eac83accc640e3c88bcf36265e1028aa48b5d (commit)
   via  dc333a7115a43e4e97a2ff3ba269a39526598f88 (commit)
   via  735c41ddb021a5ca0e8957591447acdb28a0f41b (commit)
  from  c971f751b482213ba817c4dcbffb5b2d96021120 (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=9f8eac83accc640e3c88bcf36265e1028aa48b5d
commit 9f8eac83accc640e3c88bcf36265e1028aa48b5d
Merge: c971f75 dc333a7
Author: Brad King 
AuthorDate: Tue Mar 29 14:30:24 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 14:30:24 2016 -0400

Merge topic 'update-kwsys' into next

dc333a71 Merge branch 'upstream-KWSys' into update-kwsys
735c41dd KWSys 2016-03-29 (b51abb30)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc333a7115a43e4e97a2ff3ba269a39526598f88
commit dc333a7115a43e4e97a2ff3ba269a39526598f88
Merge: 90f24f0 735c41d
Author: Brad King 
AuthorDate: Tue Mar 29 14:29:42 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 14:29:42 2016 -0400

Merge branch 'upstream-KWSys' into update-kwsys

* upstream-KWSys:
  KWSys 2016-03-29 (b51abb30)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=735c41ddb021a5ca0e8957591447acdb28a0f41b
commit 735c41ddb021a5ca0e8957591447acdb28a0f41b
Author: KWSys Upstream 
AuthorDate: Tue Mar 29 14:28:37 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 14:29:42 2016 -0400

KWSys 2016-03-29 (b51abb30)

Code extracted from:

http://public.kitware.com/KWSys.git

at commit b51abb307d3b40957cc508aa54d449d9b41f5537 (master).

Upstream Shortlog
-

Ben Boeckel (1):
  069a6b37 windows: check for _WIN32 rather than WIN32

Felix Geyer (1):
  b51abb30 SystemInformation: Fix spelling typos in comments

diff --git a/RegularExpression.cxx b/RegularExpression.cxx
index 598e7ca..22593b4 100644
--- a/RegularExpression.cxx
+++ b/RegularExpression.cxx
@@ -376,7 +376,7 @@ bool RegularExpression::compile (const char* exp) {
 }
 
 // Allocate space.
-//#ifndef WIN32
+//#ifndef _WIN32
 if (this->program != 0) delete [] this->program;
 //#endif
 this->program = new char[regsize];
diff --git a/RegularExpression.hxx.in b/RegularExpression.hxx.in
index d0235d8..0bb700f 100644
--- a/RegularExpression.hxx.in
+++ b/RegularExpression.hxx.in
@@ -333,7 +333,7 @@ inline RegularExpression::RegularExpression (const 
std::string& s)
  */
 inline RegularExpression::~RegularExpression () 
 {
-//#ifndef WIN32
+//#ifndef _WIN32
   delete [] this->program;
 //#endif
 }
@@ -396,7 +396,7 @@ inline bool RegularExpression::is_valid () const
 
 inline void RegularExpression::set_invalid () 
 {
-//#ifndef WIN32
+//#ifndef _WIN32
   delete [] this->program;
 //#endif
   this->program = 0;
diff --git a/SystemInformation.cxx b/SystemInformation.cxx
index 512d5fb..81fb2f9 100644
--- a/SystemInformation.cxx
+++ b/SystemInformation.cxx
@@ -1583,7 +1583,7 @@ 
SystemInformationImplementation::~SystemInformationImplementation()
 
 void SystemInformationImplementation::RunCPUCheck()
 {
-#ifdef WIN32
+#ifdef _WIN32
   // Check to see if this processor supports CPUID.
   bool supportsCPUID = DoesCPUSupportCPUID();
 
@@ -2056,7 +2056,7 @@ bool 
SystemInformationImplementation::DoesCPUSupportFeature(long int dwFeature)
 
 void SystemInformationImplementation::Delay(unsigned int uiMS)
 {
-#ifdef WIN32
+#ifdef _WIN32
   LARGE_INTEGER Frequency, StartCounter, EndCounter;
   __int64 x;
 
@@ -2339,7 +2339,7 @@ bool 
SystemInformationImplementation::RetrieveClassicalCPUCacheDetails()
 case 13: TLBCacheUnit = ((TLBCacheData[3] & 0x00FF) >> 16); break;
 case 14: TLBCacheUnit = ((TLBCacheData[3] & 0xFF00) >> 24); break;
 
-// Default case - an error has occured.
+// Default case - an error has occurred.
 default: return false;
 }
 
@@ -2401,7 +2401,7 @@ bool 
SystemInformationImplementation::RetrieveClassicalCPUCacheDetails()
 case 0x96: STORE_TLBCACHE_INFO (TLBCode, 262144); break;  // <-- 
FIXME: IA-64 Only
 case 0x9b: STORE_TLBCACHE_INFO (TLBCode, 262144); break;  // <-- 
FIXME: IA-64 Only
 
-// Default case - an error has occured.
+// Default case - an error has occurred.
 default: return false;
 }
   }
diff --git a/testEncoding.cxx b/testEncoding.cxx
index 842b17d..80ec040 100644
--- a/testEncoding.cxx
+++ 

[cmake-developers] [CMake 0016037]: Various typos

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16037 
== 
Reported By:Felix Geyer
Assigned To:
== 
Project:CMake
Issue ID:   16037
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   low
Status: new
== 
Date Submitted: 2016-03-29 14:06 EDT
Last Modified:  2016-03-29 14:06 EDT
== 
Summary:Various typos
Description: 
The Debian package checker tool (lintian) detected several typos in CMake
(mostly documentation).
Attached is a patch against git master.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-03-29 14:06 Felix GeyerNew Issue
2016-03-29 14:06 Felix GeyerFile Added: cmake-spelling.patch
   
==

-- 

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] zlib and pkg-config on window

[Barry Scott]

I am trying to build a couple of projects that use CMake, libssh2 and
libgit2 on Windows 10 64 bit.

I am installing all open source code into c:\OpenSource64 tree with the
usual bin, lib, include folders.

I cannot seem to find a set of -D that allows cmake to allow ZLIB and
libssh2 be found when bulding libgit2.

Do I need to point CMake at the folder with the .pc files in it?
How would I do that?

Does CMake need an implementation of pkg-config for windows?

Here are the libssh2 files that are installed:

c:\>dir OpenSource64\libssh* /s /b|find /v "share"
c:\OpenSource64\bin\libssh2.dll
c:\OpenSource64\include\libssh2.h
c:\OpenSource64\include\libssh2_config.h
c:\OpenSource64\include\libssh2_publickey.h
c:\OpenSource64\include\libssh2_sftp.h
c:\OpenSource64\lib\libssh2.dll
c:\OpenSource64\lib\libssh2.lib
c:\OpenSource64\lib\cmake\libssh2
c:\OpenSource64\lib\cmake\libssh2\Libssh2Config-release.cmake
c:\OpenSource64\lib\cmake\libssh2\Libssh2Config.cmake
c:\OpenSource64\lib\cmake\libssh2\Libssh2ConfigVersion.cmake
c:\OpenSource64\lib\pkgconfig\libssh2.pc

here is the cmake run:

C:\Users\barry\Work\libgit2-0.24.0\build.Release> cmake -G "Visual
Studio 14 2015 Win64" .. -DCMAKE_PREFIX_PATH=c:/OpenSource64
-DLIBSSH2_PREFIX=c:/OpenSource64 -- The C compiler identification is
MSVC 19.0.23026.0 -- Check for working C compiler using: Visual Studio
14 2015 Win64 -- Check for working C compiler using: Visual Studio 14
2015 Win64 -- works -- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE) 
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM - Failed
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC - Failed
-- Performing Test HAVE_STRUCT_STAT_MTIME_NSEC
-- Performing Test HAVE_STRUCT_STAT_MTIME_NSEC - Failed
-- Could NOT find ZLIB (missing:  ZLIB_LIBRARY) (found version "1.2.8")
-- zlib was not found; using bundled 3rd-party sources.
-- LIBSSH2 not found. Set CMAKE_PREFIX_PATH if it is installed outside
of the default search path. -- Looking for futimens
-- Looking for futimens - not found
-- Looking for qsort_r
-- Looking for qsort_r - not found
-- Looking for qsort_s
-- Looking for qsort_s - found
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - not found
-- Found PythonInterp: C:/python35.win64/python.exe (found version
"3.5.1") -- Configuring done
-- Generating done
-- Build files have been written to:
C:/Users/barry/Work/libgit2-0.24.0/build.Release

Adding -DZLIB_LIBRARY=c:/OpenSource64/lib/zlib1.dll leads to a link
error claiming that zlib1.dll is a corrupt file.

Atleast to dumpbin it seems that zlib1.dll is good.

Barry
-- 

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] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Ruslan Baratov via CMake]

The note about CMAKE_IOS_INSTALL_COMBINED is related to value of 
CMAKE_OSX_SYSROOT. `${EFFECTIVE_PLATFORM_NAME}` as far as I understand 
used on build step too, it's not only installation 
(`cmTarget::ComputeOutputDir`). As alternative you can try to hardcode 
`LIBRARY_OUTPUT_DIRECTORY` so both simulator and device will have same 
predictable location. I don't know about CMake internals in such depth 
to answer question about generator expression.


Ruslo

On 29-Mar-16 22:51, Vladimír Vondruš wrote:

Hm... this is unfortunate. Would it be possible to keep the 
${EFFECTIVE_PLATFORM_NAME} in place for the install step but return it 
substituted when one asks explicitly using generator expression? From what I 
understood in the docs, the CMAKE_IOS_INSTALL_COMBINED is doing something 
additional during installation step and does not affect generator step -- so I 
think a behavior specific for installation and CMAKE_IOS_INSTALL_COMBINED could 
be separated from direct use of generator expressions. Or am I completely out 
of touch?

Thank you
mosra

__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 29.03.2016 15:20
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 29-Mar-16 16:14, Vladimír Vondruš wrote:

I saw that commit, yes. Since there is no additional round of variable expansion, wouldn't it 
be better to expand the ${EFFECTIVE_PLATFORM_NAME} to at least something fixed (based on the 
value of CMAKE_OSX_SYSROOT), instead of making the generator expression unusable in all cases? 
It seems reasonable to me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the 
output of $ would be something like

  /path/to/my/build/dir/Debug-iphonesimulator/something.framework

instead of:

  /path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework

Because the latter is unusable, with the former I have at least the ability to 
use it with a single fixed SDK.

Thanks
mosra

As far as I know you have to set CMAKE_OSX_SYSROOT to "iphoneos" so
Xcode project will contain both simulator and device configuration.
Without this change such feature like CMAKE_IOS_INSTALL_COMBINED will
not work. In other words substituting `${EFFECTIVE_PLATFORM_NAME}` may
fit your needs but will broke CMAKE_IOS_INSTALL_COMBINED for everybody
(at least if this behaviour will be unconditional).

Ruslo


__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 21.03.2016 14:56
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 21-Mar-16 19:42, Vladimír Vondruš wrote:

Hello,

I came across this problem when trying to use XCTest macros ( 
https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
compiling for OSX, ctest properly executes all test cases, but when targeting 
iOS or iOS simulator, all the test cases fail similarly to the following:

   25: Test command: /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
"/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
   25: Environment variables:
   25:  
DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
   25: Test timeout computed to be: 9.99988e+06
   25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
couldn’t be loaded because its executable couldn’t be located. Try reinstalling 
the bundle.
   25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 
sec

As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
`-iphonesimulator` and thus the file is not found. The problem is that the 
`$` generator expression does not expand the 
variable. On the other hand, installation works without an issue, because the 
`cmake_install.cmake` scripts do additional round of variable expansion that 
(accidentally?) fixes this. The relevant part of the CMake source is here: 
https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

   From the source it looks like the generator is just putting the 
"${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
That's the case with install scripts (so they work), but not with generator expressions. 
The `TARGET_LINKER_FILE_DIR` is not the only affected, the problem is the same for all 
`TARGET_*` generator expressions.

Currently I'm working around this by partially hardcoding the path, but that's 
far from ideal and I would like to avoid that:

   if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
   set(platform_name 

[Cmake-commits] CMake branch, next, updated. v3.5.1-695-gc971f75

[Ben Boeckel]

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, next has been updated
   via  c971f751b482213ba817c4dcbffb5b2d96021120 (commit)
   via  07b7614e07e351ea46c32eebfc1195d6f5a18a10 (commit)
  from  46f442feed475ecaa2c43499f5bc0bbf00a60289 (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=c971f751b482213ba817c4dcbffb5b2d96021120
commit c971f751b482213ba817c4dcbffb5b2d96021120
Merge: 46f442f 07b7614
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:57:36 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 11:57:36 2016 -0400

Merge topic 'ctest-run-submodule-sync' into next

07b7614e fixup! cmCTestGIT: run git submodule {init,sync} to update


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07b7614e07e351ea46c32eebfc1195d6f5a18a10
commit 07b7614e07e351ea46c32eebfc1195d6f5a18a10
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:56:10 2016 -0400
Commit: Ben Boeckel 
CommitDate: Tue Mar 29 11:56:10 2016 -0400

fixup! cmCTestGIT: run git submodule {init,sync} to update

diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 4dd617f..ee462f8 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -273,15 +273,27 @@ bool cmCTestGIT::UpdateImpl()
   std::string top_dir = this->FindTopDir();
   const char* git = this->CommandLineTool.c_str();
   const char* recursive = "--recursive";
+  const char* sync_recursive = "--recursive";
+
+  // Git < 1.6.5 did not support submodule --recursive
+  if(this->GetGitVersion() < cmCTestGITVersion(1,6,5,0))
+{
+recursive = 0;
+// No need to require >= 1.6.5 if there are no submodules.
+if(cmSystemTools::FileExists((top_dir + "/.gitmodules").c_str()))
+  {
+  this->Log << "Git < 1.6.5 cannot update submodules recursively\n";
+  }
+}
 
   // Git < 1.8.1 did not support sync --recursive
   if(this->GetGitVersion() < cmCTestGITVersion(1,8,1,0))
 {
-recursive = 0;
+sync_recursive = 0;
 // No need to require >= 1.8.1 if there are no submodules.
 if(cmSystemTools::FileExists((top_dir + "/.gitmodules").c_str()))
   {
-  this->Log << "Git < 1.8.1 cannot update submodules recursively\n";
+  this->Log << "Git < 1.8.1 cannot synchronize submodules recursively\n";
   }
 }
 
@@ -297,7 +309,8 @@ bool cmCTestGIT::UpdateImpl()
 return false;
 }
 
-  char const* git_submodule_sync[] = {git, "submodule", "sync", recursive, 0};
+  char const* git_submodule_sync[] = {git, "submodule", "sync",
+  sync_recursive, 0};
   ret = this->RunChild(git_submodule_sync, _out, _err,
top_dir.c_str());
 

---

Summary of changes:
 Source/CTest/cmCTestGIT.cxx |   19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)


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

Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Vladimír Vondruš]

Hm... this is unfortunate. Would it be possible to keep the 
${EFFECTIVE_PLATFORM_NAME} in place for the install step but return it 
substituted when one asks explicitly using generator expression? From what I 
understood in the docs, the CMAKE_IOS_INSTALL_COMBINED is doing something 
additional during installation step and does not affect generator step -- so I 
think a behavior specific for installation and CMAKE_IOS_INSTALL_COMBINED could 
be separated from direct use of generator expressions. Or am I completely out 
of touch?

Thank you
mosra

__
> Od: Ruslan Baratov 
> Komu: "Vladimír Vondruš" 
> Datum: 29.03.2016 15:20
> Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* 
> generator expressions on iOS
>
> CC: cmake@cmake.org
>On 29-Mar-16 16:14, Vladimír Vondruš wrote:
>> I saw that commit, yes. Since there is no additional round of variable 
>> expansion, wouldn't it be better to expand the ${EFFECTIVE_PLATFORM_NAME} to 
>> at least something fixed (based on the value of CMAKE_OSX_SYSROOT), instead 
>> of making the generator expression unusable in all cases? It seems 
>> reasonable to me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the 
>> output of $ would be something like
>>
>>  /path/to/my/build/dir/Debug-iphonesimulator/something.framework
>>
>> instead of:
>>
>>  
>> /path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework
>>
>> Because the latter is unusable, with the former I have at least the ability 
>> to use it with a single fixed SDK.
>>
>> Thanks
>> mosra
>As far as I know you have to set CMAKE_OSX_SYSROOT to "iphoneos" so 
>Xcode project will contain both simulator and device configuration. 
>Without this change such feature like CMAKE_IOS_INSTALL_COMBINED will 
>not work. In other words substituting `${EFFECTIVE_PLATFORM_NAME}` may 
>fit your needs but will broke CMAKE_IOS_INSTALL_COMBINED for everybody 
>(at least if this behaviour will be unconditional).
>
>Ruslo
>
>>
>> __
>>> Od: Ruslan Baratov 
>>> Komu: "Vladimír Vondruš" 
>>> Datum: 21.03.2016 14:56
>>> Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* 
>>> generator expressions on iOS
>>>
>>> CC: cmake@cmake.org
>>> On 21-Mar-16 19:42, Vladimír Vondruš wrote:
 Hello,

 I came across this problem when trying to use XCTest macros ( 
 https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
 compiling for OSX, ctest properly executes all test cases, but when 
 targeting iOS or iOS simulator, all the test cases fail similarly to the 
 following:

   25: Test command: 
 /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
 "/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
   25: Environment variables:
   25:  
 DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
   25: Test timeout computed to be: 9.99988e+06
   25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
 couldn’t be loaded because its executable couldn’t be located. Try 
 reinstalling the bundle.
   25/28 Test #25: UtilityTypeTraitsTest ...***Failed
 0.04 sec

 As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
 `-iphonesimulator` and thus the file is not found. The problem is that the 
 `$` generator expression does not expand 
 the variable. On the other hand, installation works without an issue, 
 because the `cmake_install.cmake` scripts do additional round of variable 
 expansion that (accidentally?) fixes this. The relevant part of the CMake 
 source is here: 
 https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

   From the source it looks like the generator is just putting the 
 "${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands 
 it. That's the case with install scripts (so they work), but not with 
 generator expressions. The `TARGET_LINKER_FILE_DIR` is not the only 
 affected, the problem is the same for all `TARGET_*` generator expressions.

 Currently I'm working around this by partially hardcoding the path, but 
 that's far from ideal and I would like to avoid that:

   if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
   set(platform_name "-iphoneos")
   elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
   set(platform_name "-iphonesimulator")
   endif()
   set(target_linker_file_dir 
 

[Cmake-commits] CMake branch, next, updated. v3.5.1-693-g46f442f

[Ben Boeckel]

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, next has been updated
   via  46f442feed475ecaa2c43499f5bc0bbf00a60289 (commit)
   via  4fb6148000219c6a08c1d60ac6cb30febc2b80b2 (commit)
  from  aaf515c3532a68f33df3fc274b199c35d52205d1 (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=46f442feed475ecaa2c43499f5bc0bbf00a60289
commit 46f442feed475ecaa2c43499f5bc0bbf00a60289
Merge: aaf515c 4fb6148
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:50:15 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 11:50:15 2016 -0400

Merge topic 'external-project-no-extract' into next

4fb61480 fixup! ExternalProject: add support for just downloading a file


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4fb6148000219c6a08c1d60ac6cb30febc2b80b2
commit 4fb6148000219c6a08c1d60ac6cb30febc2b80b2
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:49:54 2016 -0400
Commit: Ben Boeckel 
CommitDate: Tue Mar 29 11:49:54 2016 -0400

fixup! ExternalProject: add support for just downloading a file

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index f2f005b..0c4d9d8 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -77,7 +77,7 @@ Create custom targets to build projects in external trees
 Path to a certificate authority file
   ``TIMEOUT ``
 Time allowed for file download operations
-  ``NO_EXTRACT 1``
+  ``DOWNLOAD_NO_EXTRACT 1``
 Just download the file and do not extract it; the full path to the
 downloaded file is available as .
 
@@ -1878,7 +1878,7 @@ function(_ep_add_download_command name)
   set(cmd   ${CMAKE_COMMAND} -E remove_directory ${source_dir}
 COMMAND ${CMAKE_COMMAND} -E copy_directory ${abs_dir} ${source_dir})
 else()
-  get_property(no_extract TARGET "${name}" PROPERTY _EP_NO_EXTRACT SET)
+  get_property(no_extract TARGET "${name}" PROPERTY 
_EP_DOWNLOAD_NO_EXTRACT SET)
   if("${url}" MATCHES "^[a-z]+://")
 # TODO: Should download and extraction be different steps?
 if("x${fname}" STREQUAL "x")

---

Summary of changes:
 Modules/ExternalProject.cmake |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.

Something like this has long been missing for compiler warnings
and optimization levels.

-Brad

One more note. Properties is a good abstraction and works great for the 
native CMake project. But there is a tricky scenario about them - when 
we need to create ExternalProject_Add for the non-CMake project.
E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to `YES` I 
need to add `-fPIC` to the flags manually, or check `CXX_STANDARD 11` 
and add `-std=c++11`. I guess I can handle such simple cases but I can 
predict that for warnings it will be a huge pain.

How CMake can help me avoid violating DRY?

Ruslo
--

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-commits] CMake branch, next, updated. v3.5.1-691-gaaf515c

[Ben Boeckel]

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, next has been updated
   via  aaf515c3532a68f33df3fc274b199c35d52205d1 (commit)
   via  1aa1a6a0e467b309ab3c93f11b99207cdf5d0924 (commit)
  from  641bc68e9a1e79d7df654f5768223238da9c820b (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=aaf515c3532a68f33df3fc274b199c35d52205d1
commit aaf515c3532a68f33df3fc274b199c35d52205d1
Merge: 641bc68 1aa1a6a
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:29:00 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 11:29:00 2016 -0400

Merge topic 'ctest-run-submodule-sync' into next

1aa1a6a0 cmCTestGIT: run git submodule {init,sync} to update


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1aa1a6a0e467b309ab3c93f11b99207cdf5d0924
commit 1aa1a6a0e467b309ab3c93f11b99207cdf5d0924
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 11:05:15 2016 -0400
Commit: Ben Boeckel 
CommitDate: Tue Mar 29 11:27:27 2016 -0400

cmCTestGIT: run git submodule {init,sync} to update

Repositories which add submodules or change their URLs are not fixed by
CTest when updating a git repository.

diff --git a/Help/release/dev/ctest-run-submodule-sync.rst 
b/Help/release/dev/ctest-run-submodule-sync.rst
new file mode 100644
index 000..55e87c0
--- /dev/null
+++ b/Help/release/dev/ctest-run-submodule-sync.rst
@@ -0,0 +1,6 @@
+ctest-run-submodule-sync
+
+
+* The :command:`ctest_update` command will now initialize and synchronize
+  submodules on an update. Updates which add submodules or change a
+  submodule's URL will now be pulled properly.
diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index bbb3b9d..4dd617f 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -274,20 +274,39 @@ bool cmCTestGIT::UpdateImpl()
   const char* git = this->CommandLineTool.c_str();
   const char* recursive = "--recursive";
 
-  // Git < 1.6.5.0 did not support --recursive
-  if(this->GetGitVersion() < cmCTestGITVersion(1,6,5,0))
+  // Git < 1.8.1 did not support sync --recursive
+  if(this->GetGitVersion() < cmCTestGITVersion(1,8,1,0))
 {
 recursive = 0;
-// No need to require >= 1.6.5.0 if there are no submodules.
+// No need to require >= 1.8.1 if there are no submodules.
 if(cmSystemTools::FileExists((top_dir + "/.gitmodules").c_str()))
   {
-  this->Log << "Git < 1.6.5.0 cannot update submodules recursively\n";
+  this->Log << "Git < 1.8.1 cannot update submodules recursively\n";
   }
 }
 
-  char const* git_submodule[] = {git, "submodule", "update", recursive, 0};
   OutputLogger submodule_out(this->Log, "submodule-out> ");
   OutputLogger submodule_err(this->Log, "submodule-err> ");
+
+  char const* git_submodule_init[] = {git, "submodule", "init", 0};
+  bool ret = this->RunChild(git_submodule_init, _out, _err,
+top_dir.c_str());
+
+  if (!ret)
+{
+return false;
+}
+
+  char const* git_submodule_sync[] = {git, "submodule", "sync", recursive, 0};
+  ret = this->RunChild(git_submodule_sync, _out, _err,
+   top_dir.c_str());
+
+  if (!ret)
+{
+return false;
+}
+
+  char const* git_submodule[] = {git, "submodule", "update", recursive, 0};
   return this->RunChild(git_submodule, _out, _err,
 top_dir.c_str());
 }

---

Summary of changes:
 Help/release/dev/ctest-run-submodule-sync.rst |6 +
 Source/CTest/cmCTestGIT.cxx   |   29 -
 2 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 Help/release/dev/ctest-run-submodule-sync.rst


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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 29-Mar-16 21:24, Brad King wrote:

On 03/29/2016 09:09 AM, Ruslan Baratov wrote:

As a general note obviously I've used another approach because I decide
to create CMake module which can be used with regular CMake versions :)
Of course implementing this in CMake "from the box" is best.

Are we talking about levels only or about control of exact kind of
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?

At a minimum we should support levels (e.g. all, default, none) that
are generic enough to have mappings to flags on every compiler.  Later
one could consider more granular switches with enumerated options that
may not all have flags on every compiler.



OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

What about generating nothing for such cases? E.g. code:

  try {
  }
  catch (...) {
  }

produce "catch-semantic-changed" warning on MSVC but it's okay for 
Clang. So we can add `/w4571` for MSVC and nothing for other compilers.




I think these warning properties should perhaps be done as usage
requirements with propagation through INTERFACE_* properties.  I'd
need to see some example use cases spelled out though.
But not if target is installed. It will be quite inconvenient if 3rd 
party package add some flags to local targets. Is it possible to support 
it from the box? Requirements are handy when we are talking about 
different code generated with different compile flags. Warnings have 
different nature. Fact that we are using `-Wall` or not using `-Wall` 
doesn't change final binary or affect compatibility.




Once such directory/target properties are available then we could look
at making them take over the role of providing default warning flags
instead of putting them in the CMAKE__FLAGS* variables.  That may
need a policy as you pointed out earlier.

-Brad

Great.


What about this:

compile_warnings # modify directory properties
target_compile_warnings # modify target properties
sources_compile_warnings # modify source properties

Same API for all:

   *_compile_warnings( DISABLE  
ENABLE  TREAT_AS_ERROR ) # may be plus 'APPEND' 
for extending instead of overwriting (?)


General warning-id's:

  * ALL
  * DEFAULT
  * LEVEL

Group warnings-id's:

  * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
  * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`


Simple warning-id examples:

  * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
  * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing

  * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Ruslo
--

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] ExternalProject + git submodule sync

[Ben Boeckel]

On Tue, Mar 29, 2016 at 10:24:26 -0400, Brad King wrote:
> Might a user want to change the url used locally?  If so then we
> need a way to turn off the automatic sync, though I think making
> it default is reasonable.

I suppose it is possible, but if you're modifying submodules behind
ExternalProject's back, you already have issues:

  - it fails to detect updates[1] not done by ExternalProject itself, so
"edit in source tree then run `make $external_project` at the
top-level" is already a non-working workflow (submodules or no);
  - if it isn't using the name of a *local* branch, when ExternalProject
runs its update step, it will leave your work behind (if it is
committed);
  - if you have modifications in a submodule, the stash commands don't
work properly (they never unapply properly and I think the only
fool-proof way to fix it is something like:
git submodule foreach --recursive cmake -P do_stash_if_necessary.cmake
cmake -P update.cmake
git submodule foreach --recursive cmake -P 
undo_stash_if_stashed_above.cmake).

So if we add support for skipping this step, it's probably more
reasonable to put a flag around having ExternalProject do *any* update
step (available for any non-tarball source really).

--Ben

[1]Though to do this properly, we need to add a dependency on every file
under the source tree.
-- 

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-commits] CMake branch, next, updated. v3.5.1-689-g641bc68

[Brad King]

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, next has been updated
   via  641bc68e9a1e79d7df654f5768223238da9c820b (commit)
   via  5c324294ce8488537c68085b187c9fe2a51664c4 (commit)
  from  83a4aec25e404a2975fcc06bf181ec1bf4941bd2 (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=641bc68e9a1e79d7df654f5768223238da9c820b
commit 641bc68e9a1e79d7df654f5768223238da9c820b
Merge: 83a4aec 5c32429
Author: Brad King 
AuthorDate: Tue Mar 29 10:33:54 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 10:33:54 2016 -0400

Merge topic 'preallocate-condition-keywords' into next

5c324294 cmConditionEvaluator: Pre-allocate keyword strings


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5c324294ce8488537c68085b187c9fe2a51664c4
commit 5c324294ce8488537c68085b187c9fe2a51664c4
Author: Brad King 
AuthorDate: Tue Mar 29 10:31:21 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 10:32:28 2016 -0400

cmConditionEvaluator: Pre-allocate keyword strings

Calls to `IsKeyword("...")` cause runtime construction of std::string.
Avoid possible repeated allocation by pre-allocating keyword strings
during initialization.

diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 6a0ebec..305ebe3 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -14,6 +14,33 @@
 #include "cmOutputConverter.h"
 #include "cmAlgorithms.h"
 
+static std::string const keyAND = "AND";
+static std::string const keyCOMMAND = "COMMAND";
+static std::string const keyDEFINED = "DEFINED";
+static std::string const keyEQUAL = "EQUAL";
+static std::string const keyEXISTS = "EXISTS";
+static std::string const keyGREATER = "GREATER";
+static std::string const keyIN_LIST = "IN_LIST";
+static std::string const keyIS_ABSOLUTE = "IS_ABSOLUTE";
+static std::string const keyIS_DIRECTORY = "IS_DIRECTORY";
+static std::string const keyIS_NEWER_THAN = "IS_NEWER_THAN";
+static std::string const keyIS_SYMLINK = "IS_SYMLINK";
+static std::string const keyLESS = "LESS";
+static std::string const keyMATCHES = "MATCHES";
+static std::string const keyNOT = "NOT";
+static std::string const keyOR = "OR";
+static std::string const keyParenL = "(";
+static std::string const keyParenR = ")";
+static std::string const keyPOLICY = "POLICY";
+static std::string const keySTREQUAL = "STREQUAL";
+static std::string const keySTRGREATER = "STRGREATER";
+static std::string const keySTRLESS = "STRLESS";
+static std::string const keyTARGET = "TARGET";
+static std::string const keyTEST = "TEST";
+static std::string const keyVERSION_EQUAL = "VERSION_EQUAL";
+static std::string const keyVERSION_GREATER = "VERSION_GREATER";
+static std::string const keyVERSION_LESS = "VERSION_LESS";
+
 cmConditionEvaluator::cmConditionEvaluator(cmMakefile& makefile,
const cmListFileContext ,
const cmListFileBacktrace& bt):
@@ -400,7 +427,7 @@ bool cmConditionEvaluator::HandleLevel0(cmArgumentList 
,
 cmArgumentList::iterator arg = newArgs.begin();
 while (arg != newArgs.end())
   {
-  if (IsKeyword("(", *arg))
+  if (IsKeyword(keyParenL, *arg))
 {
 // search for the closing paren for this opening one
 cmArgumentList::iterator argClose;
@@ -409,11 +436,11 @@ bool cmConditionEvaluator::HandleLevel0(cmArgumentList 
,
 unsigned int depth = 1;
 while (argClose != newArgs.end() && depth)
   {
-  if (this->IsKeyword("(", *argClose))
+  if (this->IsKeyword(keyParenL, *argClose))
 {
   depth++;
 }
-  if (this->IsKeyword(")", *argClose))
+  if (this->IsKeyword(keyParenR, *argClose))
 {
   depth--;
 }
@@ -474,35 +501,35 @@ bool cmConditionEvaluator::HandleLevel1(cmArgumentList 
,
   argP1 = arg;
   this->IncrementArguments(newArgs,argP1,argP2);
   // does a file exist
-  if (this->IsKeyword("EXISTS", *arg) && argP1 != newArgs.end())
+  if (this->IsKeyword(keyEXISTS, *arg) && argP1 != newArgs.end())
 {
 this->HandlePredicate(
   cmSystemTools::FileExists(argP1->c_str()),
   reducible, arg, newArgs, argP1, argP2);
 }
   // does a directory with this name exist
-  if (this->IsKeyword("IS_DIRECTORY", *arg) && argP1 != newArgs.end())
+  if (this->IsKeyword(keyIS_DIRECTORY, *arg) && argP1 != newArgs.end())
 {
  

Re: [cmake-developers] ExternalProject + git submodule sync

[Brad King]

On 03/29/2016 10:17 AM, Ben Boeckel wrote:
> I'd like to bump the minimum ExternalProject requirement to 1.8.1 from
> November 2012 (current requirement is 1.6.5 from October 2009). The
> reason is that this release introduced the `git submodule sync
> --recursive` command

Rather than a hard requirement we should adapt to any version of
Git we find, perhaps with degraded functionality.

> The usecase is for updates to the repo where the submodule URL
> changes after an update.
[snip]
> Or is it better to make the `git submodule sync --recursive`
> conditional?

Might a user want to change the url used locally?  If so then we
need a way to turn off the automatic sync, though I think making
it default is reasonable.

-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

[Cmake-commits] CMake branch, next, updated. v3.5.1-687-g83a4aec

[Ben Boeckel]

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, next has been updated
   via  83a4aec25e404a2975fcc06bf181ec1bf4941bd2 (commit)
   via  d5a5af252e1280e62bc3ec146d2baabc0f2e18d5 (commit)
  from  a2d1f4c6d990cecc9ce724758eabdb0e77d1e7a8 (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=83a4aec25e404a2975fcc06bf181ec1bf4941bd2
commit 83a4aec25e404a2975fcc06bf181ec1bf4941bd2
Merge: a2d1f4c d5a5af2
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 10:28:30 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 10:28:30 2016 -0400

Merge topic 'external-project-no-extract' into next

d5a5af25 ExternalProject: add support for just downloading a file


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d5a5af252e1280e62bc3ec146d2baabc0f2e18d5
commit d5a5af252e1280e62bc3ec146d2baabc0f2e18d5
Author: Ben Boeckel 
AuthorDate: Tue Mar 29 10:25:01 2016 -0400
Commit: Ben Boeckel 
CommitDate: Tue Mar 29 10:25:01 2016 -0400

ExternalProject: add support for just downloading a file

Some projects only ship self-extracting installers rather than
compressed archives. Add a flag so that these files may be used in
ExternalProject.

diff --git a/Help/release/dev/external-project-no-extract.rst 
b/Help/release/dev/external-project-no-extract.rst
new file mode 100644
index 000..af5d717
--- /dev/null
+++ b/Help/release/dev/external-project-no-extract.rst
@@ -0,0 +1,6 @@
+external-project-no-extract
+---
+
+* The :module:`ExternalProject` module leared the ``NO_EXTRACT 1`` argument to
+  skip extracting the file that is downloaded (e.g., for self-extracting shell
+  installers or MSI files).
diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 249658d..f2f005b 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -77,6 +77,9 @@ Create custom targets to build projects in external trees
 Path to a certificate authority file
   ``TIMEOUT ``
 Time allowed for file download operations
+  ``NO_EXTRACT 1``
+Just download the file and do not extract it; the full path to the
+downloaded file is available as .
 
   Update/Patch step options are:
 
@@ -1107,7 +1110,7 @@ macro(_ep_replace_location_tags target_name)
   set(vars ${ARGN})
   foreach(var ${vars})
 if(${var})
-  foreach(dir SOURCE_DIR BINARY_DIR INSTALL_DIR TMP_DIR)
+  foreach(dir SOURCE_DIR BINARY_DIR INSTALL_DIR TMP_DIR DOWNLOADED_FILE)
 get_property(val TARGET ${target_name} PROPERTY _EP_${dir})
 string(REPLACE "<${dir}>" "${val}" ${var} "${${var}}")
   endforeach()
@@ -1875,6 +1878,7 @@ function(_ep_add_download_command name)
   set(cmd   ${CMAKE_COMMAND} -E remove_directory ${source_dir}
 COMMAND ${CMAKE_COMMAND} -E copy_directory ${abs_dir} ${source_dir})
 else()
+  get_property(no_extract TARGET "${name}" PROPERTY _EP_NO_EXTRACT SET)
   if("${url}" MATCHES "^[a-z]+://")
 # TODO: Should download and extraction be different steps?
 if("x${fname}" STREQUAL "x")
@@ -1884,7 +1888,9 @@ function(_ep_add_download_command name)
   string(REGEX MATCH 
"([^/\\?]+(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip))/.*$" 
match_result "${url}")
   set(fname "${CMAKE_MATCH_1}")
 endif()
-if(NOT "${fname}" MATCHES 
"(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
+if (no_extract)
+  get_filename_component(fname "${url}" NAME)
+elseif(NOT "${fname}" MATCHES 
"(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
   message(FATAL_ERROR "Could not extract tarball filename from url:\n  
${url}")
 endif()
 string(REPLACE ";" "-" fname "${fname}")
@@ -1898,16 +1904,30 @@ function(_ep_add_download_command name)
 set(cmd ${CMAKE_COMMAND} -P "${download_script}"
   COMMAND)
 set(retries 3)
-set(comment "Performing download step (download, verify and extract) 
for '${name}'")
+if (no_extract)
+  set(steps "download and verify")
+else ()
+  set(steps "download, verify and extract")
+endif ()
+set(comment "Performing download step (${steps}) for '${name}'")
   else()
 set(file "${url}")
-set(comment "Performing download step (verify and extract) for 
'${name}'")
+if (no_extract)
+  set(steps "verify")
+else ()
+  set(steps "verify and extract")
+endif ()
+  

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 03/29/2016 09:09 AM, Ruslan Baratov wrote:
> As a general note obviously I've used another approach because I decide 
> to create CMake module which can be used with regular CMake versions :) 
> Of course implementing this in CMake "from the box" is best.
> 
> Are we talking about levels only or about control of exact kind of 
> warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?

At a minimum we should support levels (e.g. all, default, none) that
are generic enough to have mappings to flags on every compiler.  Later
one could consider more granular switches with enumerated options that
may not all have flags on every compiler.  OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

I think these warning properties should perhaps be done as usage
requirements with propagation through INTERFACE_* properties.  I'd
need to see some example use cases spelled out though.

Once such directory/target properties are available then we could look
at making them take over the role of providing default warning flags
instead of putting them in the CMAKE__FLAGS* variables.  That may
need a policy as you pointed out earlier.

-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

[Cmake-commits] CMake branch, next, updated. v3.5.1-685-ga2d1f4c

[Brad King]

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, next has been updated
   via  a2d1f4c6d990cecc9ce724758eabdb0e77d1e7a8 (commit)
   via  2379b3ae3171db7277fd3cf126b5b0c298231b83 (commit)
   via  02fce523a13c8e4cda0c95334b480bb87336ed1c (commit)
  from  540a816a6c02d6b1fc9f34632b7e2a5ba9422768 (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=a2d1f4c6d990cecc9ce724758eabdb0e77d1e7a8
commit a2d1f4c6d990cecc9ce724758eabdb0e77d1e7a8
Merge: 540a816 2379b3a
Author: Brad King 
AuthorDate: Tue Mar 29 10:18:44 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 10:18:44 2016 -0400

Merge topic 'simplify-condition-context' into next

2379b3ae cmConditionEvaluator: Remove GetConditionContext method
02fce523 cmConditionEvaluator: Drop unnecessary path conversion


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2379b3ae3171db7277fd3cf126b5b0c298231b83
commit 2379b3ae3171db7277fd3cf126b5b0c298231b83
Author: Brad King 
AuthorDate: Tue Mar 29 10:01:55 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 10:10:20 2016 -0400

cmConditionEvaluator: Remove GetConditionContext method

All it does is call cmListFileContext::FromCommandContext, so move this
to the call sites.

diff --git a/Source/cmConditionEvaluator.cxx b/Source/cmConditionEvaluator.cxx
index 4bfe697..5d06f40 100644
--- a/Source/cmConditionEvaluator.cxx
+++ b/Source/cmConditionEvaluator.cxx
@@ -104,18 +104,6 @@ bool cmConditionEvaluator::IsTrue(
 errorString, status, true);
 }
 
-cmListFileContext cmConditionEvaluator::GetConditionContext(
-cmMakefile*,
-const cmCommandContext& command,
-const std::string& filePath)
-{
-  cmListFileContext context =
-  cmListFileContext::FromCommandContext(
-command,
-filePath);
-  return context;
-}
-
 //=
 const char* cmConditionEvaluator::GetDefinitionIfUnquoted(
   cmExpandedCommandArgument const& argument) const
diff --git a/Source/cmConditionEvaluator.h b/Source/cmConditionEvaluator.h
index 8600825..3ed512d 100644
--- a/Source/cmConditionEvaluator.h
+++ b/Source/cmConditionEvaluator.h
@@ -33,9 +33,6 @@ public:
   std::string ,
   cmake::MessageType );
 
-  static cmListFileContext GetConditionContext(cmMakefile* mf,
-  const cmCommandContext& command, std::string const& filePath);
-
 private:
   // Filter the given variable definition based on policy CMP0054.
   const char* GetDefinitionIfUnquoted(
diff --git a/Source/cmIfCommand.cxx b/Source/cmIfCommand.cxx
index 5964ef1..9a07dde 100644
--- a/Source/cmIfCommand.cxx
+++ b/Source/cmIfCommand.cxx
@@ -108,8 +108,8 @@ IsFunctionBlocked(const cmListFileFunction& lff,
 cmake::MessageType messType;
 
 cmListFileContext conditionContext =
-cmConditionEvaluator::GetConditionContext(
-  , this->Functions[c],
+cmListFileContext::FromCommandContext(
+  this->Functions[c],
   this->GetStartingContext().FilePath);
 
 cmConditionEvaluator conditionEvaluator(
@@ -210,8 +210,8 @@ bool cmIfCommand
   commandContext.Name = execContext.Name;
 
   cmConditionEvaluator conditionEvaluator(
-*(this->Makefile), cmConditionEvaluator::GetConditionContext(
-  this->Makefile, commandContext, execContext.FilePath),
+*(this->Makefile), cmListFileContext::FromCommandContext(
+  commandContext, execContext.FilePath),
 this->Makefile->GetBacktrace());
 
   bool isTrue = conditionEvaluator.IsTrue(
diff --git a/Source/cmWhileCommand.cxx b/Source/cmWhileCommand.cxx
index 4b7afd8..aabbe27 100644
--- a/Source/cmWhileCommand.cxx
+++ b/Source/cmWhileCommand.cxx
@@ -56,8 +56,8 @@ IsFunctionBlocked(const cmListFileFunction& lff, cmMakefile 
,
   commandContext.Name = execContext.Name;
 
   cmListFileContext conditionContext =
-  cmConditionEvaluator::GetConditionContext(
-, commandContext,
+  cmListFileContext::FromCommandContext(
+commandContext,
 this->GetStartingContext().FilePath);
 
   cmConditionEvaluator conditionEvaluator(

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02fce523a13c8e4cda0c95334b480bb87336ed1c
commit 02fce523a13c8e4cda0c95334b480bb87336ed1c
Author: Brad King 
AuthorDate: Tue Mar 29 10:01:40 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 10:02:17 2016 -0400

[cmake-developers] ExternalProject + git submodule sync

[Ben Boeckel]

Hi,

I'd like to bump the minimum ExternalProject requirement to 1.8.1 from
November 2012 (current requirement is 1.6.5 from October 2009). The
reason is that this release introduced the `git submodule sync
--recursive` command (the command existed before, but the flag is new in
1.8.1). The usecase is for updates to the repo where the submodule URL
changes after an update. Without a `git submodule sync`, the submodule
URL at the time of `git submodule init` will continue to be used.

Or is it better to make the `git submodule sync --recursive`
conditional?

Branch on stage (unmerged into next):

external-project-git-submodule-sync

Thanks,

--Ben
-- 

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-commits] CMake branch, next, updated. v3.5.1-682-g540a816

[Brad King]

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, next has been updated
   via  540a816a6c02d6b1fc9f34632b7e2a5ba9422768 (commit)
   via  90f24f016e93d18f6a244b39fd21c68355bdbe48 (commit)
   via  2ab344a1dcfcc91cf7337cd700af827a60fec811 (commit)
   via  439237442237a74d2923a671fa6f71bb1678e3eb (commit)
   via  60de9b8a4fe6ceb99682ef7e63e73a592506d158 (commit)
  from  517902c3e2cd41fd2171ea20a2a5a743b04a31b2 (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=540a816a6c02d6b1fc9f34632b7e2a5ba9422768
commit 540a816a6c02d6b1fc9f34632b7e2a5ba9422768
Merge: 517902c 90f24f0
Author: Brad King 
AuthorDate: Tue Mar 29 09:24:46 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 09:24:46 2016 -0400

Merge branch 'master' into next


---

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-commits] CMake branch, master, updated. v3.5.1-331-g4392374

[Brad King]

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  439237442237a74d2923a671fa6f71bb1678e3eb (commit)
   via  1fe004eac3c5b905cb620580c3258ca3bd455c18 (commit)
  from  60de9b8a4fe6ceb99682ef7e63e73a592506d158 (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=439237442237a74d2923a671fa6f71bb1678e3eb
commit 439237442237a74d2923a671fa6f71bb1678e3eb
Merge: 60de9b8 1fe004e
Author: Brad King 
AuthorDate: Tue Mar 29 09:24:34 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 09:24:34 2016 -0400

Merge topic 'cpack-rpm-default-user-and-group'

1fe004ea cpack rpm setting of defattr


---

Summary of changes:
 .../dev/cpack-rpm-default-user-and-group.rst   |9 ++
 Modules/CPackRPM.cmake |  103 +++-
 .../MyLibCPackConfig-IgnoreGroup.cmake.in  |   14 +++
 .../RunCPackVerifyResult.cmake |   24 +
 4 files changed, 149 insertions(+), 1 deletion(-)
 create mode 100644 Help/release/dev/cpack-rpm-default-user-and-group.rst


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

[Cmake-commits] CMake branch, master, updated. v3.5.1-334-g2ab344a

[Brad King]

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  2ab344a1dcfcc91cf7337cd700af827a60fec811 (commit)
   via  36ad8dd440069b126ca28dccf57e8c65188c693b (commit)
   via  230d50ed1a1bbeac3b840ecc2d45c1b8710c8be4 (commit)
  from  439237442237a74d2923a671fa6f71bb1678e3eb (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=2ab344a1dcfcc91cf7337cd700af827a60fec811
commit 2ab344a1dcfcc91cf7337cd700af827a60fec811
Merge: 4392374 36ad8dd
Author: Brad King 
AuthorDate: Tue Mar 29 09:24:36 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 09:24:36 2016 -0400

Merge topic 'ghs-link-flags'

36ad8dd4 GHS: Implement link flags and dirs for non-target groups (#16029)
230d50ed GHS: Factor out compiler information shared among languages


---

Summary of changes:
 Modules/Compiler/GHS-C.cmake |4 ++--
 Modules/Compiler/GHS-CXX.cmake   |4 ++--
 Modules/Compiler/GHS.cmake   |8 
 Source/cmGhsMultiTargetGenerator.cxx |   34 --
 Source/cmGhsMultiTargetGenerator.h   |3 ++-
 5 files changed, 46 insertions(+), 7 deletions(-)
 create mode 100644 Modules/Compiler/GHS.cmake


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

[Cmake-commits] CMake branch, master, updated. v3.5.1-336-g90f24f0

[Brad King]

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  90f24f016e93d18f6a244b39fd21c68355bdbe48 (commit)
   via  9408a7a80259b94ac181171392849aeb944bfbb0 (commit)
  from  2ab344a1dcfcc91cf7337cd700af827a60fec811 (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=90f24f016e93d18f6a244b39fd21c68355bdbe48
commit 90f24f016e93d18f6a244b39fd21c68355bdbe48
Merge: 2ab344a 9408a7a
Author: Brad King 
AuthorDate: Tue Mar 29 09:24:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 09:24:39 2016 -0400

Merge topic 'asm-includes'

9408a7a8 ASM: Add missing  placeholder for "compile" rules


---

Summary of changes:
 Modules/CMakeASM-ATTInformation.cmake   |2 +-
 Modules/CMakeASM_NASMInformation.cmake  |2 +-
 Modules/Compiler/ARMCC-ASM.cmake|2 +-
 Modules/Platform/Generic-ADSP-ASM.cmake |2 +-
 Modules/Platform/gas.cmake  |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.5.1-677-g517902c

[Brad King]

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, next has been updated
   via  517902c3e2cd41fd2171ea20a2a5a743b04a31b2 (commit)
   via  9408a7a80259b94ac181171392849aeb944bfbb0 (commit)
  from  6d53569de4fa16b230d38d61551ed5b09be71fe6 (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=517902c3e2cd41fd2171ea20a2a5a743b04a31b2
commit 517902c3e2cd41fd2171ea20a2a5a743b04a31b2
Merge: 6d53569 9408a7a
Author: Brad King 
AuthorDate: Tue Mar 29 09:21:04 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 09:21:04 2016 -0400

Merge topic 'asm-includes' into next

9408a7a8 ASM: Add missing  placeholder for "compile" rules


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9408a7a80259b94ac181171392849aeb944bfbb0
commit 9408a7a80259b94ac181171392849aeb944bfbb0
Author: Gregor Jasny 
AuthorDate: Fri Mar 25 23:18:07 2016 +0100
Commit: Brad King 
CommitDate: Tue Mar 29 09:19:10 2016 -0400

ASM: Add missing  placeholder for "compile" rules

This placeholder was added to the compilation rules for other languages
by commit v3.4.0-rc1~342^2 (Factor an  placeholder out of
 in rule variables, 2015-07-13) but ASM was incorrectly left out.

Signed-off-by: Gregor Jasny 

diff --git a/Modules/CMakeASM-ATTInformation.cmake 
b/Modules/CMakeASM-ATTInformation.cmake
index 675c13b..07a2d38 100644
--- a/Modules/CMakeASM-ATTInformation.cmake
+++ b/Modules/CMakeASM-ATTInformation.cmake
@@ -19,7 +19,7 @@ set(ASM_DIALECT "-ATT")
 # assembler but should be processed by gcc
 set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS s;asm)
 
-set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT " 
 -o  ")
+set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT " 
  -o  ")
 
 include(CMakeASMInformation)
 set(ASM_DIALECT)
diff --git a/Modules/CMakeASM_NASMInformation.cmake 
b/Modules/CMakeASM_NASMInformation.cmake
index 7058fc7..146f412 100644
--- a/Modules/CMakeASM_NASMInformation.cmake
+++ b/Modules/CMakeASM_NASMInformation.cmake
@@ -38,7 +38,7 @@ if(NOT CMAKE_ASM_NASM_OBJECT_FORMAT)
   endif()
 endif()
 
-set(CMAKE_ASM_NASM_COMPILE_OBJECT "  -f 
${CMAKE_ASM_NASM_OBJECT_FORMAT} -o  ")
+set(CMAKE_ASM_NASM_COMPILE_OBJECT "  
 -f ${CMAKE_ASM_NASM_OBJECT_FORMAT} -o  ")
 
 # Load the generic ASMInformation file:
 set(ASM_DIALECT "_NASM")
diff --git a/Modules/Compiler/ARMCC-ASM.cmake b/Modules/Compiler/ARMCC-ASM.cmake
index 8e3cfc5..539d525 100644
--- a/Modules/Compiler/ARMCC-ASM.cmake
+++ b/Modules/Compiler/ARMCC-ASM.cmake
@@ -3,5 +3,5 @@ include(Compiler/ARMCC)
 set(CMAKE_ASM_OUTPUT_EXTENSION ".o")
 set(CMAKE_ASM_OUTPUT_EXTENSION_REPLACE 1)
 
-set(CMAKE_ASM_COMPILE_OBJECT   "  -o  
")
+set(CMAKE_ASM_COMPILE_OBJECT   "   -o 
 ")
 set(CMAKE_ASM_SOURCE_FILE_EXTENSIONS s;asm;msa)
diff --git a/Modules/Platform/Generic-ADSP-ASM.cmake 
b/Modules/Platform/Generic-ADSP-ASM.cmake
index 63a1388..e718bec 100644
--- a/Modules/Platform/Generic-ADSP-ASM.cmake
+++ b/Modules/Platform/Generic-ADSP-ASM.cmake
@@ -3,5 +3,5 @@ include(Platform/Generic-ADSP-Common)
 set(CMAKE_ASM_SOURCE_FILE_EXTENSIONS asm)
 set(CMAKE_ASM_OUTPUT_EXTENSION ".doj" )
 set(CMAKE_ASM_COMPILE_OBJECT
-"  -proc ${ADSP_PROCESSOR} -si-revision 
${ADSP_PROCESSOR_SILICIUM_REVISION} -o  ")
+"   -proc ${ADSP_PROCESSOR} 
-si-revision ${ADSP_PROCESSOR_SILICIUM_REVISION} -o  ")
 
diff --git a/Modules/Platform/gas.cmake b/Modules/Platform/gas.cmake
index 7d2bc84..7c659f2 100644
--- a/Modules/Platform/gas.cmake
+++ b/Modules/Platform/gas.cmake
@@ -4,7 +4,7 @@ else()
   set(CMAKE_ASM${ASM_DIALECT}_OUTPUT_EXTENSION .obj)
 endif()
 
-set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT " 
 -o  ")
+set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT " 
  -o  ")
 
 set(CMAKE_ASM${ASM_DIALECT}_CREATE_STATIC_LIBRARY
   " cr"

---

Summary of changes:


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

Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Ruslan Baratov via CMake]

On 29-Mar-16 16:14, Vladimír Vondruš wrote:

I saw that commit, yes. Since there is no additional round of variable expansion, wouldn't it 
be better to expand the ${EFFECTIVE_PLATFORM_NAME} to at least something fixed (based on the 
value of CMAKE_OSX_SYSROOT), instead of making the generator expression unusable in all cases? 
It seems reasonable to me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the 
output of $ would be something like

 /path/to/my/build/dir/Debug-iphonesimulator/something.framework

instead of:

 /path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework

Because the latter is unusable, with the former I have at least the ability to 
use it with a single fixed SDK.

Thanks
mosra
As far as I know you have to set CMAKE_OSX_SYSROOT to "iphoneos" so 
Xcode project will contain both simulator and device configuration. 
Without this change such feature like CMAKE_IOS_INSTALL_COMBINED will 
not work. In other words substituting `${EFFECTIVE_PLATFORM_NAME}` may 
fit your needs but will broke CMAKE_IOS_INSTALL_COMBINED for everybody 
(at least if this behaviour will be unconditional).


Ruslo



__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 21.03.2016 14:56
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 21-Mar-16 19:42, Vladimír Vondruš wrote:

Hello,

I came across this problem when trying to use XCTest macros ( 
https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
compiling for OSX, ctest properly executes all test cases, but when targeting 
iOS or iOS simulator, all the test cases fail similarly to the following:

  25: Test command: /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
"/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
  25: Environment variables:
  25:  
DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
  25: Test timeout computed to be: 9.99988e+06
  25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
couldn’t be loaded because its executable couldn’t be located. Try reinstalling 
the bundle.
  25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 sec

As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
`-iphonesimulator` and thus the file is not found. The problem is that the 
`$` generator expression does not expand the 
variable. On the other hand, installation works without an issue, because the 
`cmake_install.cmake` scripts do additional round of variable expansion that 
(accidentally?) fixes this. The relevant part of the CMake source is here: 
https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

  From the source it looks like the generator is just putting the 
"${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
That's the case with install scripts (so they work), but not with generator expressions. 
The `TARGET_LINKER_FILE_DIR` is not the only affected, the problem is the same for all 
`TARGET_*` generator expressions.

Currently I'm working around this by partially hardcoding the path, but that's 
far from ideal and I would like to avoid that:

  if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
  set(platform_name "-iphoneos")
  elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
  set(platform_name "-iphonesimulator")
  endif()
  set(target_linker_file_dir 
${CMAKE_CURRENT_BINARY_DIR}/$${platform_name}/${target}.xctest)

Is there any way to fix this directly in CMake? Also the above workaround works 
only when targeting single SDK and not when having single generated project for 
both the device and the simulator.

Thank you a lot for your help.

mosra

I doubt I can help with the problem but just for your information:
* it wasn't fixed "accidentally", it was a fix for #12506:
https://github.com/Kitware/CMake/commit/48fe617e667d2e6b1e471cfb56346de51f984ba5
* there is no "additional round" of variable expansion,
EFFECTIVE_PLATFORM_NAME initialized from Xcode's environment variable
EFFECTIVE_PLATFORM_NAME on installation

As far as I understand the main general problem with iOS
device/simulator support is that CMake doesn't have multi-toolchain
feature from the box. So for now all this stuff worked by generating
some "universal" code that do work for both SDKs. The real SDK can be
triggered by additional explicit option, i.e.:
* cmake --build _builds -- -sdk iphoneos # trigger iphoneos SDK
* cmake --build _builds -- -sdk iphonesimulator # trigger
iphonesimulator SDK

Ruslo



--

Powered by www.kitware.com

Please keep messages on-topic and 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 12:49, Geoffrey Viola wrote:


Thanks for the feedback. I’ll have to look more in-depth at Xcode 
specific issues.


> Take a look at this approach:
> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

What exactly is sophisticated? API of `sugar_generate_warning_flags` 
function? Probably this is because it covering much more functionality 
that your approach, no? Also you can use this to create new function 
with more simple API. That is you can make `set_warning_level_high` 
using call to `sugar_generate_warning_flags` but there is no function 
(at least in the currently attached patch) that can set `-Wall` in 
cross-platform fashion for only one target.


The API that I’m supporting has global commands for simple, small 
projects and then a slightly more sophisticated set of commands around 
targets and source files. It’s supposed to remove the need of knowing 
compiler specific flags from the user, although they can be manually 
edited in CMake as always.


May be I'm missing something but there is no need to know compiler 
specific flags when using `sugar_generate_warning_flags`. In sense that 
when you set `conversion` then module will add `-Wconversion` for Clang 
and GCC, `4244` for MSVC and CLANG_WARN_SUSPICIOUS_IMPLICIT_CONVERSION 
for Xcode. From my practice there must be an abstraction that is linked 
to the exact type of warning because without `-Werror` warnings are 
quite useless and if you combine it with `-Wall -Weverything` there will 
be a lot of warning that I don't want to fix, like `-Wpadded` that 
produce warning like for every C++ class definition in the project.


The choice of flags for the various compilers are different between 
the two APIs. My API merely turns the warnings up without triggering 
false positives. It may miss some useful warnings. For example, my API 
uses /W4 instead of /Wall for MSVC. I’ve seen /Wall provide some 
additional useful warnings, but also some distracting, informational 
ones. There are a few users who agree that some of the /Wall warnings 
are more informational at 
http://stackoverflow.com/questions/4001736/whats-up-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall. 
Also, I should probably include –Wextra for the GCC warnings like 
yours does.


I think you should not make such decisions in code like "I know that /W4 
is better than /Wall" or "I'm sure -Wshadow is useless". That definitely 
up to user.


Ruslo


From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake API for warnings

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more 
fine control options like target_compile_options (i.e. different 
target may have different warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties


Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> 
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so 
it will not set `/W3` (or any other warning flags) by default. May be 
introduce new policy (?)


Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:

CMake should support an API to manage compiler warnings to simplify a 
common problem. Using more compilers with high levels of warnings 
means cheap static analysis and better conformance to standard C++.


Compiler warnings are an easy way to increase program reliability. A 
use case would be to increase compilation warnings on all internal 
code, ignore warnings on all 3rd party code, and treat all warnings as 
errors.


Attached is an initial attempt to control warnings in CMake. The API 
has a short name (e.g. set_warnings_as_errors) for simplicity and a 
more technical name (e.g. set_warnings_as_errors_folder) to specify 
scope. Note that the short name acts on CMake’s folder scope and is 
meant to be global. The current compilers considered are GCC, clang, 
Green Hills, and MSVC. A CMake Warning is issued if the macro does not 
support a specific compiler so that conformance can be guaranteed.


Thanks,

Geoffrey Viola

This message contains confidential information and is intended only 
for the recipient. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this e-mail by mistake and delete 
this e-mail from your system. Finally, the recipient should check this 
email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.
As a general note obviously I've used another approach because I decide 
to create CMake module which can be used with regular CMake versions :) 
Of course implementing this in CMake "from the box" is best.


Are we talking about levels only or about control of exact kind of 
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?


Ruslo



Something like this has long been missing for compiler warnings
and optimization levels.

-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

[Cmake-commits] CMake branch, next, updated. v3.5.1-675-g6d53569

[Brad King]

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, next has been updated
   via  6d53569de4fa16b230d38d61551ed5b09be71fe6 (commit)
   via  729f5f01b4a1798ad8e11d3dc4eae664af96bd23 (commit)
  from  ae8dbb9d619d83104c5afa9029b084064ae8c566 (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=6d53569de4fa16b230d38d61551ed5b09be71fe6
commit 6d53569de4fa16b230d38d61551ed5b09be71fe6
Merge: ae8dbb9 729f5f0
Author: Brad King 
AuthorDate: Tue Mar 29 08:46:42 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Mar 29 08:46:42 2016 -0400

Merge topic 'vs-fortran-MP' into next

729f5f01 VS: Map Intel Fortran `/MP` flag for multi-processor compilation 
(#15990)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=729f5f01b4a1798ad8e11d3dc4eae664af96bd23
commit 729f5f01b4a1798ad8e11d3dc4eae664af96bd23
Author: Brad King 
AuthorDate: Tue Mar 29 08:42:33 2016 -0400
Commit: Brad King 
CommitDate: Tue Mar 29 08:45:00 2016 -0400

VS: Map Intel Fortran `/MP` flag for multi-processor compilation (#15990)

diff --git a/Source/cmLocalVisualStudio7Generator.cxx 
b/Source/cmLocalVisualStudio7Generator.cxx
index abae564..2f66517 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -378,6 +378,11 @@ cmVS7FlagTable 
cmLocalVisualStudio7GeneratorFortranFlagTable[] =
   {"FloatingPointExceptionHandling", "fpe:1", "", "fpe1", 0},
   {"FloatingPointExceptionHandling", "fpe:3", "", "fpe3", 0},
 
+  {"MultiProcessorCompilation", "MP", "", "true",
+   cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue},
+  {"ProcessorNumber", "MP", "Multi-processor Compilation", "",
+   cmVS7FlagTable::UserValueRequired},
+
   {"ModulePath", "module:", "", "",
cmVS7FlagTable::UserValueRequired},
   {"LoopUnrolling", "Qunroll:", "", "",

---

Summary of changes:
 Source/cmLocalVisualStudio7Generator.cxx |5 +
 1 file changed, 5 insertions(+)


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

Re: [cmake-developers] CPackRPM not dealing correctly with symlinks

[Attila Krasznahorkay]

Hi Domen,

I just tried, it seems to do the trick. An example source setup that was 
breaking the RPM building before, is now functioning seemingly correctly. The 
produced RPM gets the symlink, pointing at the location outside of the package.

I would actually prefer if the code printed a warning in this case. (Requesting 
a relocatable package, yet pointing at a fixed location outside of the 
package.) As in our case it was definitely a mistake to include soft links like 
this in our build. But if that's hard to add to the code, then so be it.

Cheers,
 Attila

> On 28 Mar 2016, at 18:38, Domen Vrankar  wrote:
> 
> Attached is CPackRPM.cmake that fixes cases where symlink points to
> locations outside packaging directory.
> 
> Please confirm that it fixes your problem. Patched CPackRPM.cmake is
> from master branch so please replace the file in your 3.5.0 version of
> CMake.
> 
> Thanks,
> Domen
> 
> 2016-03-24 9:48 GMT+01:00 Attila Krasznahorkay 
> :
>> Hi Domen,
>> 
>> Unfortunately I can't seem to create an easy-to-package example for the 
>> issue. Since it seems that the file given to the install(...) command has to 
>> be in a "very different place" than the source or binary directories for the 
>> issue to come up. (My guess is that if the file shares some of its path with 
>> the build directory, CPackRPM uses a different method for dealing with it 
>> than if the two paths don't share any prefix.)
>> 
>> In our case some files are picked up from a network drive, while the build 
>> happens (naturally) on a local drive. I can reproduce the issue with a 
>> CMakeLists.txt file like:
>> 
>> cmake_minimum_required( VERSION 2.8 )
>> project( CPackRPMLinkProblem )
>> 
>> install( FILES /afs/cern.ch/.../some_link.txt DESTINATION . )
>> 
>> set( CPACK_PACKAGE_RELOCATABLE TRUE )
>> include( CPack )
>> 
>> As long as the build directory's path name ends up being longer than the 
>> path name of the file specified in the install(...) command, the RPM 
>> building fails. As it does for instance here:
>> 
>> http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49AnlOpt/NICOS_Log_rel_4/nicos_rpm_build.html
>> 
>> Cheers,
>>   Attila
>> 
>>> On 23 Mar 2016, at 15:57, Domen Vrankar  wrote:
>>> 
>>> As a workaround you could set files that you would like to be excluded
>>> from symlink relocation with CPACK_RPM_USER_FILELIST or
>>> CPACK_RPM__USER_FILELIST.
>>> 
>>> I'll have a look at how this could be solved for later versions of CPack.
>>> Do I understand correctly that those errors occur when a symlink is
>>> pointing to another simlink outside your project?
>>> Could you please provide a minimal example of all your cases?
>>> 
>>> Thanks,
>>> Domen
>>> 
>>> 
>>> 2016-03-23 14:13 GMT+01:00 Attila Krasznahorkay
>>> :
 Hi Brad,
 
 I did. Then I get:
 
 CMake Error at 
 /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:981
  (string):
 string begin index: 164 is out of range 0 - 156
 Call Stack (most recent call first):
 /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1625
  (cpack_rpm_prepare_install_files)
 /afs/cern.ch/work/k/krasznaa/public/cmake/3.5.0/share/cmake-3.5/Modules/CPackRPM.cmake:1787
  (cpack_rpm_generate_package)
 
 You can find the full output here:
 
 http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/nightlies/experimentalWebArea/nicos_web_areaCMAKE64BS6G49TrgOpt/NICOS_Log_rel_3/nicos_rpm_build.html
 
 Note that when I tried to build the project in a build area with a shorter 
 path, then the RPM building succeeded. Just because by chance in that case 
 in the expression
 
 string(SUBSTRING "${SYMLINK_POINT_}" ${WDR_LEN_} -1 SYMLINK_POINT_WD_)
 
 the work directory length was shorter than the length of the path outside 
 of the project.
 
 Of course this is the code that we're talking about:
 
 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CPackRPM.cmake;h=7ffec136deabb8f28d6293cdc96e43cd4a2af70d;hb=HEAD#l994
 
 Cheers,
Attila
 
> On 23 Mar 2016, at 13:50, Brad King  wrote:
> 
> On 03/23/2016 08:44 AM, Attila Krasznahorkay wrote:
>> CMake Error at /afs/cern.ch/sw/lcg/contrib/CMake/3.3.2/...
> 
> Please try with CMake 3.5.
> 
> -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: 

Re: [CMake] CMAKE_SIZEOF_VOID_P is unset when building libgit2 on Windows

[Sebastian Schuberth]

On 3/29/2016 11:39, Sebastian Schuberth wrote:

>>$ cat CMakeLists.txt
>>cmake_minimum_required(VERSION 3.5)
>>project(test C)
>>message("${CMAKE_SIZEOF_VOID_P}")
>>
>> If that reproduces the problem, try configuring with --debug-trycompile
>> so that the CMakeFiles/CmakeTmp/CMakeFiles/cmTC_*.dir/build.make files
>> will be left behind for inspection.
> 
> Yes, that does reproduce the issue, ${CMAKE_SIZEOF_VOID_P} evaluates to an 
> empty string. I was looking at the CMakeFiles/cmTC_21eb3.dir/build.make file 
> for CMakeCCompilerABI but was not seeing any suspicious. Calling
> 
> $ /c/Ruby-DevKit/bin/make -f CMakeFiles/cmTC_21eb3.dir/build.make 
> cmTC_21eb3.exe
> 
> Also successfully builds the executable.
> 
> What should I try next?

Ok, I seem to have found the root cause of the problem. Altough CMake is 
correctly using gcc from C:/Ruby-DevKit/mingw/bin/gcc.exe, it's using gmake 
from C:/Strawberry/c/bin/gmake.exe (which is from Strawberry Perl that I also 
have installed). Ruby-DevKit does not come with gmake.exe, only with 
bin/make.exe (and with mingw/bin/mingw32-make.exe). But for some reason CMake 
seems to prefer gmake over make, despite the latter coming from the same parent 
directory than gcc.

While C:/Ruby-DevKit/bin/make.exe is an executable linked against MSYS-1.0.DLL 
that understands Unix-style paths on Windows, C:/Strawberry/c/bin/gmake.exe is 
a native Windows exeutable linked against MSVCRT.DLL that does not. Removing 
C:/Strawberry/c/bin from PATH so that CMake doe snot find gmake properly works 
around the issue for me.

So far, so good, but I'm yet unsure what's the best / most generic fix for 
this. As Ruby-DevKit is based on MSYS, I tried to replace "Unix Makefiles" in

$ cmake .. -DBUILD_CLAR=OFF -DTHREADSAFE=ON -DBUILD_SHARED_LIBS=OFF 
-DCMAKE_C_FLAGS=-fPIC -DCMAKE_BUILD_TYPE=RelWithDebInfo -G "Unix Makefiles"

with "MSYS Makefiles" so that it reads

$ cmake .. -DBUILD_CLAR=OFF -DTHREADSAFE=ON -DBUILD_SHARED_LIBS=OFF 
-DCMAKE_C_FLAGS=-fPIC -DCMAKE_BUILD_TYPE=RelWithDebInfo -G "MSYS Makefiles"

and that seems to work.

Brad, do you think that's a reasonable fix? What's the difference between 
CMake's "Unix Makefiles" and "MSYS Makefiles" anyway?

Regards,
Sebastian


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMAKE_SIZEOF_VOID_P is unset when building libgit2 on Windows

[Sebastian Schuberth]

On 3/28/2016 16:09, Brad King wrote:

>> /usr/bin/sh: -c: line 0: syntax error near unexpected token `('
>> /usr/bin/sh: -c: line 0: `C:/Ruby-DevKit/mingw/bin/gcc.exe-fPIC
>> -o CMakeFiles/cmTC_c0166.dir/CMakeCCompilerABI.c.obj   -c \C:/Program
>> Files (x86)/CMake/share/cmake-3.5/Modules/CMakeCCompilerABI.c\'
>> CMakeFiles/cmTC_c0166.dir/build.make:65: recipe for target
>> 'CMakeFiles/cmTC_c0166.dir/CMakeCCompilerABI.c.obj' failed
>> ---8<---
>>
>> There seems to be some problem in escaping the non-alphanumeric chars
>> in the path to "CMakeCCompilerABI.c".
> 
> Strange.  CMake is regularly used from "C:/Program Files (x86)/CMake".
> 
>> Any hint how to debug this further?
> 
> Try running the logged compiler command line by hand:
> 
>C:/Ruby-DevKit/mingw/bin/gcc.exe -c "C:/Program Files 
> (x86)/CMake/share/cmake-3.5/Modules/CMakeCCompilerABI.c"

This seems to work, with no output on the console and an exit code of 0.

> Also try configuring a small test project in a fresh build tree:
> 
>   $ cat CMakeLists.txt
>   cmake_minimum_required(VERSION 3.5)
>   project(test C)
>   message("${CMAKE_SIZEOF_VOID_P}")
> 
> If that reproduces the problem, try configuring with --debug-trycompile
> so that the CMakeFiles/CmakeTmp/CMakeFiles/cmTC_*.dir/build.make files
> will be left behind for inspection.

Yes, that does reproduce the issue, ${CMAKE_SIZEOF_VOID_P} evaluates to an 
empty string. I was looking at the CMakeFiles/cmTC_21eb3.dir/build.make file 
for CMakeCCompilerABI but was not seeing any suspicious. Calling

$ /c/Ruby-DevKit/bin/make -f CMakeFiles/cmTC_21eb3.dir/build.make cmTC_21eb3.exe

Also successfully builds the executable.

What should I try next?

Regards,
Sebastian


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Vladimír Vondruš]

I saw that commit, yes. Since there is no additional round of variable 
expansion, wouldn't it be better to expand the ${EFFECTIVE_PLATFORM_NAME} to at 
least something fixed (based on the value of CMAKE_OSX_SYSROOT), instead of 
making the generator expression unusable in all cases? It seems reasonable to 
me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the output of 
$ would be something like

/path/to/my/build/dir/Debug-iphonesimulator/something.framework

instead of:

/path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework

Because the latter is unusable, with the former I have at least the ability to 
use it with a single fixed SDK.

Thanks
mosra

__
> Od: Ruslan Baratov 
> Komu: "Vladimír Vondruš" 
> Datum: 21.03.2016 14:56
> Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* 
> generator expressions on iOS
>
> CC: cmake@cmake.org
>On 21-Mar-16 19:42, Vladimír Vondruš wrote:
>> Hello,
>>
>> I came across this problem when trying to use XCTest macros ( 
>> https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
>> compiling for OSX, ctest properly executes all test cases, but when 
>> targeting iOS or iOS simulator, all the test cases fail similarly to the 
>> following:
>>
>>  25: Test command: 
>> /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
>> "/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
>>  25: Environment variables:
>>  25:  
>> DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
>>  25: Test timeout computed to be: 9.99988e+06
>>  25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
>> couldn’t be loaded because its executable couldn’t be located. Try 
>> reinstalling the bundle.
>>  25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 
>> sec
>>
>> As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
>> `-iphonesimulator` and thus the file is not found. The problem is that the 
>> `$` generator expression does not expand the 
>> variable. On the other hand, installation works without an issue, because 
>> the `cmake_install.cmake` scripts do additional round of variable expansion 
>> that (accidentally?) fixes this. The relevant part of the CMake source is 
>> here: 
>> https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063
>>
>>  From the source it looks like the generator is just putting the 
>> "${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
>> That's the case with install scripts (so they work), but not with generator 
>> expressions. The `TARGET_LINKER_FILE_DIR` is not the only affected, the 
>> problem is the same for all `TARGET_*` generator expressions.
>>
>> Currently I'm working around this by partially hardcoding the path, but 
>> that's far from ideal and I would like to avoid that:
>>
>>  if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
>>  set(platform_name "-iphoneos")
>>  elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
>>  set(platform_name "-iphonesimulator")
>>  endif()
>>  set(target_linker_file_dir 
>> ${CMAKE_CURRENT_BINARY_DIR}/$${platform_name}/${target}.xctest)
>>
>> Is there any way to fix this directly in CMake? Also the above workaround 
>> works only when targeting single SDK and not when having single generated 
>> project for both the device and the simulator.
>>
>> Thank you a lot for your help.
>>
>> mosra
>I doubt I can help with the problem but just for your information:
>* it wasn't fixed "accidentally", it was a fix for #12506: 
>https://github.com/Kitware/CMake/commit/48fe617e667d2e6b1e471cfb56346de51f984ba5
>* there is no "additional round" of variable expansion, 
>EFFECTIVE_PLATFORM_NAME initialized from Xcode's environment variable 
>EFFECTIVE_PLATFORM_NAME on installation
>
>As far as I understand the main general problem with iOS 
>device/simulator support is that CMake doesn't have multi-toolchain 
>feature from the box. So for now all this stuff worked by generating 
>some "universal" code that do work for both SDKs. The real SDK can be 
>triggered by additional explicit option, i.e.:
>* cmake --build _builds -- -sdk iphoneos # trigger iphoneos SDK
>* cmake --build _builds -- -sdk iphonesimulator # trigger 
>iphonesimulator SDK
>
>Ruslo
>
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: 

Re: [CMake] Debian SID / CMake 3.5.0-1 / FindBoost / CTest

[Vincent Huber]

Thank you for your precise and clear answer !

2016-03-29 10:54 GMT+02:00 Nils Gladitz :

> On 03/29/2016 10:31 AM, Vincent Huber wrote:
>
> Hello everyone,
>
> In a CTest process, I have to determine the Boost_VERSION.
> To do so, I just add FIND_PACKAGE(Boost) to my configuration file.
> I didn’t had any problems since a cmake update on Debian/SID to cmake
> 3.5.0.
>
> From now, I have:
> -- Looking for boost CMake Error at
> /usr/share/cmake-3.5/Modules/FindBoost.cmake:896 (add_library): Unknown
> CMake command "add_library". Call Stack (most recent call first):
> /home/vhuber/feelpp/cmake/dashboard/testsuite.cmake:328 (FIND_PACKAGE)​
>
> ​If I run a standard cmake process with a FIND_PACKAGE(Boost) everything
> goes well.
>
> I do not clearly understand what is going on.
>
>
> add_library() is used by an increasing number of find modules to define
> IMPORTED targets.
> IMPORTED targets are the preferred and most convenient way to use
> libraries located by find modules.
>
> Since add_library() is only meaningful in build system definitions it is
> not available to ctest.
>
> ​I do not have theses problems with cmake 3.4.3
>
> What can I do to solve that problem ?
>
>
> You haven't mentioned why you need to determine the Boost version in your
> ctest script but if you do still require it I would implement custom logic
> (you could base it on the existing logic in FindBoost.cmake).
>
> Using library find modules from any context other than cmake project files
> is ill defined even before the changes that introduced imported targets.
> The boost find module specifically uses compiler and platform information
> that is not available in ctest scripts (e.g. boost library file names can
> be mangled differently depending on which compilers/versions are used and
> can be located differently depending on bitness).
>
> Nils
>
>


-- 
Docteur Ingénieur de recherche
CeMoSiS  - vincent.hu...@cemosis.fr
Tel: +33 (0)3 68 8*5 02 06*
IRMA - 7, rue René Descartes
67 000 Strasbourg
-- 

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] Debian SID / CMake 3.5.0-1 / FindBoost / CTest

[Nils Gladitz]

On 03/29/2016 10:31 AM, Vincent Huber wrote:


Hello everyone,

In a |CTest| process, I have to determine the |Boost_VERSION|.
To do so, I just add |FIND_PACKAGE(Boost)| to my configuration file.
I didn’t had any problems since a |cmake| update on Debian/SID to 
cmake 3.5.0.


From now, I have:
|-- Looking for boost CMake Error at 
/usr/share/cmake-3.5/Modules/FindBoost.cmake:896 (add_library): 
Unknown CMake command "add_library". Call Stack (most recent call 
first): /home/vhuber/feelpp/cmake/dashboard/testsuite.cmake:328 
(FIND_PACKAGE)|​


​If I run a standard |cmake| process with a |FIND_PACKAGE(Boost)| 
everything goes well.


I do not clearly understand what is going on.



add_library() is used by an increasing number of find modules to define 
IMPORTED targets.
IMPORTED targets are the preferred and most convenient way to use 
libraries located by find modules.


Since add_library() is only meaningful in build system definitions it is 
not available to ctest.



​I do not have theses problems with cmake 3.4.3

What can I do to solve that problem ?



You haven't mentioned why you need to determine the Boost version in 
your ctest script but if you do still require it I would implement 
custom logic (you could base it on the existing logic in FindBoost.cmake).


Using library find modules from any context other than cmake project 
files is ill defined even before the changes that introduced imported 
targets.
The boost find module specifically uses compiler and platform 
information that is not available in ctest scripts (e.g. boost library 
file names can be mangled differently depending on which 
compilers/versions are used and can be located differently depending on 
bitness).


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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Debian SID / CMake 3.5.0-1 / FindBoost / CTest

[Vincent Huber]

Hello everyone,

In a CTest process, I have to determine the Boost_VERSION.
To do so, I just add FIND_PACKAGE(Boost) to my configuration file.
I didn’t had any problems since a cmake update on Debian/SID to cmake 3.5.0.

>From now, I have:
-- Looking for boost CMake Error at
/usr/share/cmake-3.5/Modules/FindBoost.cmake:896 (add_library): Unknown
CMake command "add_library". Call Stack (most recent call first):
/home/vhuber/feelpp/cmake/dashboard/testsuite.cmake:328 (FIND_PACKAGE)​

​If I run a standard cmake process with a FIND_PACKAGE(Boost) everything
goes well.

I do not clearly understand what is going on.

​I do not have theses problems with cmake 3.4.3

What can I do to solve that problem ?

All the best,

VH​
​
-- 
Docteur Ingénieur de recherche
CeMoSiS  - vincent.hu...@cemosis.fr
Tel: +33 (0)3 68 8*5 02 06*
IRMA - 7, rue René Descartes
67 000 Strasbourg
-- 

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] Check if a variable contains valid number

[Rolf Eike Beer]

Am 2016-03-29 09:03, schrieb Lloyd:

Hi,

How can I check if the user supplied value is a valid positive integer 
or

not?

I have tried the following, but it is not entering the if condition, 
what

might be wrong? Is there a better solution?

SET(MY_NUMBER "100" CACHE STRING " Please enter the number")
string(REGEX MATCH "^[1-9][0-9]*$" MY_NUMBER  ${MY_NUMBER})
if(MY_NUMBER)

   #This area is not getting executed, whats wrong here

endif()


Have you tried this:

  if (MY_NUMBER MATCHES "^[0-9]+$")

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:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] How to debug missing dart images from ctest in cdash?

[Nyall Dawson]

(please forgive the cross-posting from the cdash list also, I'm not
sure where this issue lies)

I'm currently hitting an issue I can't resolve with submission of
ctest results to cdash. Our project makes heavy use of
DartMeasurementFile to display expected/rendered image results on
cdash. This works fine for most set ups, and images are correctly
displayed on our dash (eg, see
http://dash.orfeo-toolbox.org/testDetails.php?test=39250586=222727).

However, we've recently deployed a new build on Travis which makes use
of cmake version 3.5, and using this build we cannot get the dart
measurement files to display. An example output is
http://dash.orfeo-toolbox.org/testDetails.php?test=39284628=222801
. The test code has not changed, and the same DartMeasurementFile
messages are being output by the tests, but they are just ignored by
ctest/cdash and we do not see the images for these builds.

I've spent some time trying to debug this, but I'm stumped. Is there
anything different with cmake 3.5 which would explain this behaviour?

Kind regards,
Nyall
-- 

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] Check if a variable contains valid number

[Lloyd]

Hi,

How can I check if the user supplied value is a valid positive integer or
not?

I have tried the following, but it is not entering the if condition, what
might be wrong? Is there a better solution?

SET(MY_NUMBER "100" CACHE STRING " Please enter the number")
string(REGEX MATCH "^[1-9][0-9]*$" MY_NUMBER  ${MY_NUMBER})
if(MY_NUMBER)

   #This area is not getting executed, whats wrong here

endif()

Thanks,
  Lloyd
-- 

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