[cmake-developers] [ANNOUNCE] CMake 3.6.0-rc1 now ready for testing!

2016-06-03 Thread Robert Maynard 
I am proud to announce the first CMake 3.6 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant features of CMake 3.6 are:

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link binaries without custom flags or scripts.

* A "_CLANG_TIDY" target property and supporting
  "CMAKE__CLANG_TIDY" variable were introduced to tell the
  Makefile Generators and the "Ninja" generator to run "clang-tidy"
  along with the compiler for "C" and "CXX" languages.

* The "ExternalProject" module leared the "GIT_SHALLOW 1" option to
  perform a shallow clone of a Git repository.

* The "ExternalProject" module learned to initialize Git submodules
  recursively and also to initialize new submodules on updates.  Use
  the "GIT_SUBMODULES" option to restrict which submodules are
  initalized and updated.

* The "InstallRequiredSystemLibraries" module learned a new
  "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment
  of the Windows Universal CRT libraries with Visual Studio 2015.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX
  platforms.

Deprecated and Removed Features
===

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

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

* The "Visual Studio 7" generator (for VS .NET 2002) has been
  removed. It had been deprecated since CMake 3.3.

* The "Visual Studio 6" generator has been removed. It had been
  deprecated since CMake 3.3.



CMake 3.6 Release Notes
***

Changes made since CMake 3.5 include the following.


New Features



Generators
--

* The "Ninja" generator learned to produce phony targets of the form
  "sub/dir/all" to drive the build of a subdirectory. This is
  equivalent to "cd sub/dir; make all" with Makefile Generators.

* The "Ninja" generator now includes system header files in build
  dependencies to ensure correct re-builds when system packages are
  updated.

* The "Visual Studio 14 2015" generator learned to support the
  Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This
  feature is experimental.


Commands


* The "add_custom_command()" and "add_custom_target()" commands
  learned how to use the "CROSSCOMPILING_EMULATOR" executable target
  property.

* The "install()" command learned a new "EXCLUDE_FROM_ALL" option to
  leave installation rules out of the default installation.

* The "list()" command gained a "FILTER" sub-command to filter list
  elements by regular expression.

* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained
  support for the "%s" placeholder.  This is the number of seconds
  since the UNIX Epoch.

* The "try_compile()" command source file signature now honors
  configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in
  the generated test project.  Previously only the default such flags
  for the current toolchain were used.


Variables
-

* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell
  Makefile Generators to limit dependency scanning only to files in
  the project source and build trees.

* A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate
  when CMake is running on an Oracle Solaris host.

* A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added
  for use by toolchain files to specify system include directories to
  be appended to all compiler command lines.

* The "CMAKE__STANDARD_LIBRARIES" variable is now documented.
  It is intended for use by toolchain files to specify system
  libraries to be added to all linker command lines.

* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell
  the "Ninja" generator to configure the generated "build.ninja" file
  for use as a "subninja".

* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for
  use by toolchain files to specify platform-specific variables that
  must be propagated by the "try_compile()" command into test
  projects.

* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally
  tell the "try_compile()" command to build a static library instead
  of an executable.  This is useful for cross-compiling toolchains
  that cannot link

Re: [cmake-developers] Support libarchive 3.2

2016-06-03 Thread Brad King 
On 06/03/2016 11:39 AM, Orion Poplawski wrote:
> libarchive 3.2 changed the version string format.  The attached patch fixes.

Thanks, applied:

 FindLibArchive: Support libarchive 3.2 version string format
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38d18bab

I've queued this for merge to 'release' for 3.6.0 since it is
an environmental regression.  However, it won't be in 3.6.0-rc1
because we've already started building that.

-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-developers] [CMake 0016135]: RPATH linker flags no longer set correctly for SunOS PathScale compiler since cmake 3.1

2016-06-03 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16135 
== 
Reported By:Michał Górny
Assigned To:
== 
Project:CMake
Issue ID:   16135
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-06-03 12:47 EDT
Last Modified:  2016-06-03 12:47 EDT
== 
Summary:RPATH linker flags no longer set correctly for SunOS
PathScale compiler since cmake 3.1
Description: 
We've recently upgraded CMake and noticed that our project stopped building
correctly. After timesome debugging, I've found out that after CMake upgrade,
CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG is no longer set correctly. This happens on
SunOS-5 system with PathScale compiler in use, and it started to happen in
cmake-3.1.

It looks that the correct linker flags are being set in two modules:
Platform/SunOS.cmake and Platform/SunOS-GNU.cmake.

The former of the files does not apply the linker flags since it is restricted
to apply to SunOS-4 only.

The latter of the files used to apply before cmake-3.1. However, since cmake-3.1
it is no longer used when PathScale compiler is in use.

Steps to Reproduce: 
1. Download PathScale compiler
(http://www.pathscale.com/ekopath-compiler-suite),

2. echo 'message(FATAL_ERROR "${CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG}")' >
CMakeLists.txt

3. cmake . -DCMAKE_C_COMPILER=/opt/ekopath/bin/pathcc

With cmake-3.0.2 and older, it will print: -Wl,-R

With cmake-3.1.3 and newer, it will print an empty string

Additional Information: 
This probably could be fixed two ways: either by applying the 'GNU' rules for
PathScale compiler, or by extending the SunOS rules to SunOS-5. I don't know
which one is more correct here.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-06-03 12:47 Michał Górny   New Issue
==

-- 

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] Support libarchive 3.2

2016-06-03 Thread Orion Poplawski 
libarchive 3.2 changed the version string format.  The attached patch fixes.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
>From 92c47b8786fdd41f4b9d882386b7acf585f1c00a Mon Sep 17 00:00:00 2001
From: Orion Poplawski 
Date: Fri, 3 Jun 2016 09:37:03 -0600
Subject: [PATCH] Support libarchive 3.2 version string format

---
 Modules/FindLibArchive.cmake | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Modules/FindLibArchive.cmake b/Modules/FindLibArchive.cmake
index 471a4f1..dd93041 100644
--- a/Modules/FindLibArchive.cmake
+++ b/Modules/FindLibArchive.cmake
@@ -42,14 +42,15 @@ mark_as_advanced(LibArchive_INCLUDE_DIR LibArchive_LIBRARY)
 
 # Extract the version number from the header.
 if(LibArchive_INCLUDE_DIR AND EXISTS "${LibArchive_INCLUDE_DIR}/archive.h")
-  # The version string appears in one of two known formats in the header:
+  # The version string appears in one of three known formats in the header:
   #  #define ARCHIVE_LIBRARY_VERSION "libarchive 2.4.12"
   #  #define ARCHIVE_VERSION_STRING "libarchive 2.8.4"
-  # Match either format.
-  set(_LibArchive_VERSION_REGEX "^#define[ \t]+ARCHIVE[_A-Z]+VERSION[_A-Z]*[ \t]+\"libarchive +([0-9]+)\\.([0-9]+)\\.([0-9]+)[^\"]*\".*$")
+  #  #define ARCHIVE_VERSION_ONLY_STRING "3.2.0"
+  # Match any format.
+  set(_LibArchive_VERSION_REGEX "^#define[ \t]+ARCHIVE[_A-Z]+VERSION[_A-Z]*[ \t]+\"(libarchive +)?([0-9]+)\\.([0-9]+)\\.([0-9]+)[^\"]*\".*$")
   file(STRINGS "${LibArchive_INCLUDE_DIR}/archive.h" _LibArchive_VERSION_STRING LIMIT_COUNT 1 REGEX "${_LibArchive_VERSION_REGEX}")
   if(_LibArchive_VERSION_STRING)
-string(REGEX REPLACE "${_LibArchive_VERSION_REGEX}" "\\1.\\2.\\3" LibArchive_VERSION "${_LibArchive_VERSION_STRING}")
+string(REGEX REPLACE "${_LibArchive_VERSION_REGEX}" "\\2.\\3.\\4" LibArchive_VERSION "${_LibArchive_VERSION_STRING}")
   endif()
   unset(_LibArchive_VERSION_REGEX)
   unset(_LibArchive_VERSION_STRING)
-- 
1.8.3.1

-- 

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] CMake execute_process/signal_handler on Unix

2016-06-03 Thread Yordanov, Dimitar 
Hi Brad,

thanks for pointing me to the report. I should have searched myself:)
The POSIX alternative to the self pipe trick is using a pselect
In [1] is an article on LWN about it.

Best
Dimitar

1 - https://lwn.net/Articles/176911/

* Brad King  [16-06-03 17:00 CEST]:
> On 06/03/2016 02:05 AM, Yordanov, Dimitar wrote:
> >> Are you running inside some kind of virtualization or emulation
> >> environment?
> > 
> > Actually not. The server is maybe under heavy load, but should it
> > matter?
> 
> See discussion here:
> 
>   https://cmake.org/Bug/view.php?id=15873
> 
> > Possibly I'm on the wrong track, but couldn't the compiler reorder the
> > code where kwsysProcess is set, and move it out of the blocked
> > section? Should it be volatile to avoid such scenario?
> 
> I think further investigation/debugging would be needed to answer that.
> 
> > I thought (void)write(...); is a portable way to say that we are not
> > interested in the return value. Not that I would change running code
> > for that.
> 
> I think we used to have that and some compilers warned anyway.
> 
> -Brad
> 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake execute_process/signal_handler on Unix

2016-06-03 Thread Brad King 
On 06/03/2016 02:05 AM, Yordanov, Dimitar wrote:
>> Are you running inside some kind of virtualization or emulation
>> environment?
> 
> Actually not. The server is maybe under heavy load, but should it
> matter?

See discussion here:

  https://cmake.org/Bug/view.php?id=15873

> Possibly I'm on the wrong track, but couldn't the compiler reorder the
> code where kwsysProcess is set, and move it out of the blocked
> section? Should it be volatile to avoid such scenario?

I think further investigation/debugging would be needed to answer that.

> I thought (void)write(...); is a portable way to say that we are not
> interested in the return value. Not that I would change running code
> for that.

I think we used to have that and some compilers warned anyway.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake execute_process/signal_handler on Unix

2016-06-03 Thread Yordanov, Dimitar 
Hi Brad,

thanks for responding!

* Brad King  [16-06-01 17:18 CEST]:
> On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote:
> > I'm looking into an issue with a CMake build on Linux hanging in a
> > select syscall, when using EXECUTE_PROCESS without any additional
> > arguments. The subprocess executed is "chmod". The child finishes and
> > is marked as a zombie, but CMake did not realize that. The only
> > descriptors left open are the one of the signaling pipe.
> 
> The code in question uses a well-known idiom to make SIGCHLD
> select()able.  It has worked well for years on many platforms.
> Are you running inside some kind of virtualization or emulation
> environment?

Actually not. The server is maybe under heavy load, but should it
matter?

> 
> > is the use of a shared variable "kwsysProcesses" in the signal
> > handler. I think the usage of non volatile shared objects should be
> > avoided in signal handlers and we should just do as less as we
> > can in there.
> 
> IIRC we suppress signals while updating the shared variables.
> CMake also doesn't use threads.

Possibly I'm on the wrong track, but couldn't the compiler reorder the
code where kwsysProcess is set, and move it out of the blocked
section? Should it be volatile to avoid such scenario?

> > Why do we need the "(void)pipeStatus;" lines. For debugging?
> 
> Some compilers complain we don't use the return value of write().
> Therefore we must assign it to a variable.  Then compilers
> complain that the variable is assigned a value that is never
> used.  The cast suppresses this.

I thought (void)write(...); is a portable way to say that we are not
interested in the return value. Not that I would change running code
for that.

> > Why do we need to read from the pipe in the signal handler?
> 
> If many signals are received in succession before the select()
> wakes up and reads from the pipe then it could fill the pipe
> and block in the handler.  We do a non-blocking read to make
> sure the pipe never has more than one byte in it.  All we care
> about is waking up any blocking select().

The write end is also non-blocking so it would not block the signal
handler. I was just trying to understand the implementation and if I'm
not misunderstanding something.

> 
> BTW, in the long run I'd like to drop this code completely and
> move to libuv.  Meanwhile I'd rather not spend too much time
> updating the existing implementation.

Thanks for sharing.

Best wishes
Dimitar

> 
> -Brad
> 
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Productbuild CPack generator

2016-06-03 Thread Domen Vrankar 
> Does anyone here know if we have test coverage already for some cpack
> generators where we create a package, then unpack it to verify the results?
>

Tests/CPackComponentsDEB (Deb), Tests/CPackComponentsForAll (RPM) and tests
in Tests/RunCMake/CPack (at the moment Deb, RPM, TGZ) all verify content of
generated packages.

I intended for Tests/RunCMake/CPack to be the location of all tests for
CPack generated packages that can be verified with command line tools in a
way that you specify the type of test and if other generators have the same
capabilities they should use the same test with additional generator
specific variables in a separate file.
Unfortunately atm there are still some issues with those tests with the
most annoying being the verbosity because of:
- test should automatically cover different packaging styles [monolithic,
components, ...],
- for most tests files count and content should be the same with each
generator's Helpers.cmake providing the format (at the moment each test has
to provide special ExpectedFiles cmake script so it's too complicated to
write tests)

It's on my TODO list to extend Tests/RunCMake/CPack so hopefully I'll get
to it in the following week or two.
If you'd like to add your tests to it there is a README.txt file there that
explains how it works and how to add your own tests to it.

Regards,
Domen
-- 

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