[cmake-developers] [PATCH] Fix args handling in cmake -E time

[Andrey Pokrovskiy]

>From 7b01d1aed22b16fd81c3ae47dd51311e9a15187a Mon Sep 17 00:00:00 2001
From: wonder-mice 
Date: Tue, 19 Jan 2016 18:13:10 -0800
Subject: [PATCH] Fix args handling in cmake -E time

Previous implementation had two issues:
* Quotes in arguments where not escaped
* No special treatment for arguments with spaces

Because of that, following command line:
  cmake -E time cmake "-GUnix Makefile"
was interpreted as
  cmake -E time cmake "-GUnix" "Makefile"
Proposed patch fixes that by escaping all quotes in arguments and
wrapping all arguments in quotes before concatenating them.
---
 Source/cmAlgorithms.h | 2 +-
 Source/cmcmd.cxx  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Source/cmAlgorithms.h b/Source/cmAlgorithms.h
index ef607d2..5b76429 100644
--- a/Source/cmAlgorithms.h
+++ b/Source/cmAlgorithms.h
@@ -230,7 +230,7 @@ template
 std::string cmJoin(Range const& r, std::string delimiter)
 {
   return cmJoin(r, delimiter.c_str());
-};
+}

 template
 typename Range::const_iterator cmRemoveN(Range& r, size_t n)
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index fb7b1f5..5643cb9 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -555,7 +555,7 @@ int
cmcmd::ExecuteCMakeCommand(std::vector& args)
 // Clock command
 else if (args[1] == "time" && args.size() > 2)
   {
-  std::string command = cmJoin(cmMakeRange(args).advance(2), " ");
+  std::string command = cmWrap('"', cmMakeRange(args).advance(2),
'"', " ");

   clock_t clock_start, clock_finish;
   time_t time_start, time_finish;
-- 
2.5.4 (Apple Git-61)


0001-Fix-args-handling-in-cmake-E-time.patch
Description: Binary data
-- 

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] [patch] New find module FindXalanC

[Roger Leigh]

On 19/01/2016 19:14, Brad King wrote:

On 01/19/2016 12:02 PM, Roger Leigh wrote:

+find_package(XercesC 3.0.0 REQUIRED)


I think this is an assumption leaking from my own usage of it. I've
removed the version here.


Thanks.  The CMakeOnly.AllFindModules and FindModulesExecuteAll
tests fail when XercesC is not available.  It should be required
only if XalanC is required (XalanC_FIND_REQUIRED).


This should be fixed now.


Thanks,
Roger

--

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] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

[Taylor Braun-Jones]

On Tue, Jan 19, 2016 at 4:18 PM, Brad King  wrote:
> On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote:
>> For ExternalProjects built with a multi-config generator like "Visual
>> Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch:
>>
>> https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1
>>
>> Otherwise, the test step gives the error "Test not available without
>> configuration."
>
> Good catch.  Please try these changes:
>
>  ExternalProject: Simplify `cmake --build` configuration passing
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b95be1cf
>
>  ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f565f9fa

Thanks - works!

However, these patches use the deprecated $ generator
expression instead of $. The rest of ExternalProject.cmake
uses $.

Taylor
-- 

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] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

[Brad King]

On 01/19/2016 03:54 PM, Taylor Braun-Jones wrote:
> For ExternalProjects built with a multi-config generator like "Visual
> Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch:
> 
> https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1
> 
> Otherwise, the test step gives the error "Test not available without
> configuration."

Good catch.  Please try these changes:

 ExternalProject: Simplify `cmake --build` configuration passing
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b95be1cf

 ExternalProject: Fix TEST_BEFORE_INSTALL for multi-config generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f565f9fa

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] BUG: Pass --build-config option to ctest for multi-config ExternalProjects

[Taylor Braun-Jones]

For ExternalProjects built with a multi-config generator like "Visual
Studio 12" with `TEST_BEFORE_INSTALL ON` I need this patch:

https://github.com/Kitware/CMake/compare/master...nocnokneo:patch-1

Otherwise, the test step gives the error "Test not available without
configuration."

Thanks,
Taylor
-- 

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] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Mon, Jan 11, 2016 at 5:16 PM, Stephen Kelly  wrote:
> Taylor Braun-Jones wrote:
>
>> Consider library project Foo that uses a header-only project Bar. In
>> FooConfig.cmake, it is a important to ensure any projects using Foo also
>> use the exact same version of Bar that Foo was originally built with
>
> COMPATIBLE_INTERFACE_STRING and similar properties are designed for that use
> case.
>
> You would populate an INTERFACE_ property on the INTERFACE target, which is
> whitelisted already:
>
>  
> https://cmake.org/cmake/help/v3.4/manual/cmake-buildsystem.7.html#compatible-interface-properties
>
>  http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/5813

Thanks - that's exactly what I was looking for!

Taylor
-- 

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] [PATCH 0/3] FindwxWidgets improvements

[Rolf Eike Beer]

Am Dienstag, 19. Januar 2016, 14:25:15 schrieb Brad King:
> On 09/09/2015 11:01 AM, Brad King wrote:
> >  FindwxWidgets: allow specifying required version
> >  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5
> 
> This introduced a regression reported here:
> 
>  https://cmake.org/Bug/view.php?id=15928
> 
> The version extraction from the header is breaking the reported case.
> 
> > + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS}
> > NO_DEFAULT_PATH)
> This call is affected by CMAKE_FIND_ROOT_PATH.  Please take a look.

A random collection of thoughts I have on this:

-"_filename" is a bad name for something that is find_* set in any module. 
Really. Since the value is also in the cache with older CMake releases I think 
this name is also used at another place, so here is not searched at all or so.

-reading with file(STRINGS) will put much less stuff in the list that is REGEX 
REPLACEd later, which is probably much more efficient (depending on how large 
the file is)

-maybe call to find_file can be omitted at all, and instead just FOREACH loop 
over the include dirs and simply if(EXISTS) check if the header is there

Eike

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [ANNOUNCE] CMake 3.4.2 available for download

[Robert Maynard]

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

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

Thanks for your support!

-
Changes in 3.4.2 since 3.4.1:

Brad King (6):
CMakeDetermineCompilerId: Fix VS Itanium platform name (#15889)
VS: Do not select a partial Windows 10 SDK folder (#15831)
VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation (#15894)
cmSystemTools: Add VersionCompareEqual helper
VS: Fix Windows 10 SDK version selection (#15831)
CMake 3.4.2

Marc Chevrier (2):
FindJava: Fix typos in IdlJ and JarSigner component implementation
AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW
-- 

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] [PATCH] FindPNG: Create an imported PNG::PNG target

[Brad King]

On 01/19/2016 12:43 PM, Sam Thursfield wrote:
> Imported targets are now the recommended way of dealing with external
> library dependencies.

Thanks!  Applied with minor doc format fixup and merged to 'next'
for testing:

 FindPNG: Create an imported PNG::PNG target (#15911)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9451ea5a

> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}")

Shouldn't this refer to zlib instead of png libraries again?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns

[Harry Mallon]

Yep. The headers are the same version to version but provide a function to 
retrieve a filled version struct.

H

Harry Mallon

CODEX | Software Engineer

60 Poland Street | London | England | W1F 7NT

E ha...@codexdigital.com | T +44 203 7000 
989

Website | Facebook 
| Twitter

[http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]

On 19 Jan 2016 19:30, Brad King  wrote:
On 01/19/2016 12:03 PM, Harry Mallon wrote:
> I cannot retrieve a version number without linking and interrogating
> the library. I could be missing something though.

Are you saying that the only API provided by the package in question
to get its version number is a runtime call?  There is no version
number provided by its header files as a preprocessor macro?

-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] Access output from CheckCXXSourceRuns and CheckCSourceRuns

[Brad King]

On 01/19/2016 12:03 PM, Harry Mallon wrote:
> I cannot retrieve a version number without linking and interrogating
> the library. I could be missing something though.

Are you saying that the only API provided by the package in question
to get its version number is a runtime call?  There is no version
number provided by its header files as a preprocessor macro?

-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] [PATCH] FindALSA: Create an imported ALSA:ASound target

[Brad King]

On 01/19/2016 11:50 AM, Sam Thursfield wrote:
> Imported targets are now the recommended way of dealing with external
> library dependencies.

Thanks!  Adding Roger Leigh to Cc because he has implemented several
of these for other modules.

> +  set(ALSA_LIBRARIES ${ALSA_LIBRARY})
> +  set(ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR})
> +
> +  if(NOT TARGET ALSA::ASound)
> +add_library(ALSA::ASound UNKNOWN IMPORTED)
> +set_target_properties(ALSA::ASound PROPERTIES
> +  IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> +  IMPORTED_LOCATION "${ALSA_LIBRARY}"
> +  INTERFACE_INCLUDE_DIRECTORIES "${ALSA_INCLUDE_DIRS}"
> +  INTERFACE_LIBRARIES "${ALSA_LIBRARY}"

We shouldn't need to use INTERFACE_LIBRARIES here.  The IMPORTED_LOCATION
of an imported library should be enough to get it linked.

-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] [PATCH 0/3] FindwxWidgets improvements

[Brad King]

On 09/09/2015 11:01 AM, Brad King wrote:
>  FindwxWidgets: allow specifying required version
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5

This introduced a regression reported here:

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

The version extraction from the header is breaking the reported case.

> + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} 
> NO_DEFAULT_PATH)

This call is affected by CMAKE_FIND_ROOT_PATH.  Please take a look.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] New find module FindXalanC

[Brad King]

On 01/19/2016 12:02 PM, Roger Leigh wrote:
>>> +find_package(XercesC 3.0.0 REQUIRED)
> 
> I think this is an assumption leaking from my own usage of it. I've 
> removed the version here.

Thanks.  The CMakeOnly.AllFindModules and FindModulesExecuteAll
tests fail when XercesC is not available.  It should be required
only if XalanC is required (XalanC_FIND_REQUIRED).

-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] [PATCH] FindPNG: Create an imported PNG::PNG target

[Sam Thursfield]

Imported targets are now the recommended way of dealing with external
library dependencies.

The documentation for FindPNG is rewritten slightly.

This commit also adds a test case, you can run it like this:

cmake ... -DCMake_TEST_FindPNG=ON
ctest -R FindPNG --output-on-failure

The testcase requires the libpng library and headers to be installed.

This change is based on the equivalent changes to FindTIFF, found in
commit ebaca6290d2c0be7dec22452389632949a700d28.

https://cmake.org/Bug/view.php?id=15911
---
 Help/release/dev/FindPNG-imported-targets.rst |  4 +++
 Modules/FindPNG.cmake | 50 +++
 Tests/CMakeLists.txt  |  4 +++
 Tests/FindPNG/CMakeLists.txt  | 10 ++
 Tests/FindPNG/Test/CMakeLists.txt | 16 +
 Tests/FindPNG/Test/main.c | 20 +++
 6 files changed, 97 insertions(+), 7 deletions(-)
 create mode 100644 Help/release/dev/FindPNG-imported-targets.rst
 create mode 100644 Tests/FindPNG/CMakeLists.txt
 create mode 100644 Tests/FindPNG/Test/CMakeLists.txt
 create mode 100644 Tests/FindPNG/Test/main.c

diff --git a/Help/release/dev/FindPNG-imported-targets.rst 
b/Help/release/dev/FindPNG-imported-targets.rst
new file mode 100644
index 000..e0d0ab1
--- /dev/null
+++ b/Help/release/dev/FindPNG-imported-targets.rst
@@ -0,0 +1,4 @@
+FindPNG-imported-targets
+
+
+* The :module:`FindPNG` module now provides imported targets.
diff --git a/Modules/FindPNG.cmake b/Modules/FindPNG.cmake
index 7cf3f22..d1d5e67 100644
--- a/Modules/FindPNG.cmake
+++ b/Modules/FindPNG.cmake
@@ -2,13 +2,20 @@
 # FindPNG
 # ---
 #
-# Find the native PNG includes and library
+# Find libpng, the official reference library for the PNG image format.
 #
+# Imported targets
+# 
 #
+# This module defines the following :prop_tgt:`IMPORTED` target:
 #
-# This module searches libpng, the library for working with PNG images.
+# ``PNG::PNG``
+#   The libpng library, if found.
 #
-# It defines the following variables
+# Result variables
+# 
+#
+# This module will set the following variables in your project:
 #
 # ``PNG_INCLUDE_DIRS``
 #   where to find png.h, etc.
@@ -22,19 +29,22 @@
 # ``PNG_VERSION_STRING``
 #   the version of the PNG library found (since CMake 2.8.8)
 #
-# Also defined, but not for general use are
+# Obsolete variables
+# ^^^
+#
+# The following variables may also be set, for backwards compatibility:
 #
 # ``PNG_LIBRARY``
 #   where to find the PNG library.
-#
-# For backward compatiblity the variable PNG_INCLUDE_DIR is also set.
-# It has the same value as PNG_INCLUDE_DIRS.
+# ``PNG_INCLUDE_DIR``
+#   where to find the PNG headers (same as PNG_INCLUDE_DIRS)
 #
 # Since PNG depends on the ZLib compression library, none of the above
 # will be defined unless ZLib can be found.
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2016 Raumfeld
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -105,6 +115,32 @@ if(ZLIB_FOUND)
 endif()
   endif ()
 
+  if(NOT TARGET PNG::PNG)
+add_library(PNG::PNG UNKNOWN IMPORTED)
+set_target_properties(PNG::PNG PROPERTIES
+  INTERFACE_COMPILE_DEFINITIONS "${PNG_DEFINITIONS}"
+  INTERFACE_INCLUDE_DIRECTORIES "${PNG_INCLUDE_DIRS}"
+  INTERFACE_LIBRARIES "${PNG_LIBRARIES}")
+if(EXISTS "${PNG_LIBRARY}")
+  set_target_properties(PNG::PNG PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+IMPORTED_LOCATION "${PNG_LIBRARY}")
+endif()
+if(EXISTS "${PNG_LIBRARY_DEBUG}")
+  set_property(TARGET PNG::PNG APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(PNG::PNG PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
+IMPORTED_LOCATION_DEBUG "${PNG_LIBRARY_DEBUG}")
+endif()
+if(EXISTS "${PNG_LIBRARY_RELEASE}")
+  set_property(TARGET PNG::PNG APPEND PROPERTY
+IMPORTED_CONFIGURATIONS RELEASE)
+  set_target_properties(PNG::PNG PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
+IMPORTED_LOCATION_RELEASE "${PNG_LIBRARY_RELEASE}")
+endif()
+  endif()
   endif ()
 
   if (PNG_PNG_INCLUDE_DIR AND EXISTS "${PNG_PNG_INCLUDE_DIR}/png.h")
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 043b757..3cca77b 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1375,6 +1375,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 add_subdirectory(FindOpenSSL)
   endif()
 
+  if(CMake_TEST_FindPNG)
+add_subdirectory(FindPNG)
+  endif()
+
   if(CMake_TEST_FindTIFF)
 add_subdirectory(FindTIFF)
   endif()
diff --git a/Test

Re: [cmake-developers] Access output from CheckCXXSourceRuns and CheckCSourceRuns

[Harry Mallon]

Inline responses.


Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989
> On 19 Jan 2016, at 15:42, Brad King  wrote:
>
> On 01/18/2016 01:32 PM, Harry Mallon wrote:
>> https://github.com/Kitware/CMake/pull/209
>> This passes through the output of the run (as well as the return value)
>> so that users can access any output without using try_run.
>
> Thanks.  The signature of the macro takes a variable for the return value
> to be stored.  We need something similar to control the name of the variable
> used to store the output.  This could either be done with an optional/named
> argument or simply by documenting that the output will come in `_OUTPUT`.

Sounds sensible

> We also need to define what happens when the check has already been run.
> The normal `` result is cached to prevent repeat runs of the check.
> I don't think we can reasonably cache the entire output of the run and
> provide it on later re-runs of CMake when the check does not actually run.

I agree, we shouldn't be caching all of that

> OTOH your use case for extracting versions may have other solutions.
> We generally try to avoid try_run because it only works when the toolchain
> targets the host architecture and so does not work when cross compiling
> in general.  Look at what Modules/CMakeDetermineCompilerId.cmake does to
> extract the compiler id and version information.  It also leaves files
> in build trees under CMakeFiles/${CMAKE_VERSION}/CompilerIdC that you
> can see.  Basically it encodes the needed information in strings that
> can be extracted from the binaries without running them.

I have read CMakeDetermineCompilerId.cmake but I can't see how I can use that 
kind of an approach. Having static const char* set by the preprocessor is a 
good idea for the reasons that you mention but I cannot retrieve a version 
number without linking and interrogating the library. I could be missing 
something though.

H

-- 

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] [patch] New find module FindXalanC

[Roger Leigh]

On 19/01/2016 16:50, Brad King wrote:

On 01/19/2016 11:39 AM, Roger Leigh wrote:

Merged into next from the staging branch "xalanc" for review and
testing.  Includes a couple of unit tests to validate.  Since it depends
on XercesC, I hope what I've done here for the imported and non-imported
target cases is OK.


Thanks.  Please also add a Help/release/dev/FindXalanC.rst release note
that mentions the new module.


Done.  I can add more detail if needed here.


I've updated one of our nightly testing machines to enable the new test
for this topic.


+find_package(XercesC 3.0.0 REQUIRED)

>

Please add a comment here justifying use of this particular version number.
Explain that/why it does not depend on the XalanC version requested.


I think this is an assumption leaking from my own usage of it. I've 
removed the version here.



+# ``XalanC_LIBRARIES``
+# Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also
+# required


Our convention is to include dependencies in reported values automatically.
See FindPNG for its use of ZLIB, for example.


OK, I've updated this to match.


Thanks,
Roger

--

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] [PATCH] FindALSA: Create an imported ALSA:ASound target

[Sam Thursfield]

Imported targets are now the recommended way of dealing with external
library dependencies.

The documentation for FindALSA is rewritten slightly.

This commit also adds a test case, you can run it like this:

cmake ... -DCMake_TEST_FindALSA=ON
ctest -R FindALSA --output-on-failure

The testcase requires the libasound library and headers to be installed.

This change is based on the equivalent changes to FindTIFF, found in
commit ebaca6290d2c0be7dec22452389632949a700d28.
---
 Modules/FindALSA.cmake | 51 --
 Tests/CMakeLists.txt   |  4 +++
 Tests/FindALSA/CMakeLists.txt  | 10 
 Tests/FindALSA/Test/CMakeLists.txt | 16 
 Tests/FindALSA/Test/main.c | 12 +
 5 files changed, 80 insertions(+), 13 deletions(-)
 create mode 100644 Tests/FindALSA/CMakeLists.txt
 create mode 100644 Tests/FindALSA/Test/CMakeLists.txt
 create mode 100644 Tests/FindALSA/Test/main.c

diff --git a/Modules/FindALSA.cmake b/Modules/FindALSA.cmake
index 5c30eb9..7f98250 100644
--- a/Modules/FindALSA.cmake
+++ b/Modules/FindALSA.cmake
@@ -2,28 +2,42 @@
 # FindALSA
 # 
 #
-# Find alsa
+# Find the alsa libraries (asound).
 #
-# Find the alsa libraries (asound)
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` target:
 #
-#   This module defines the following variables:
-#  ALSA_FOUND   - True if ALSA_INCLUDE_DIR & ALSA_LIBRARY are found
-#  ALSA_LIBRARIES   - Set when ALSA_LIBRARY is found
-#  ALSA_INCLUDE_DIRS - Set when ALSA_INCLUDE_DIR is found
+# ``ALSA::ASound``
+#   The asound library, if found.
 #
+# Result variables
+# 
 #
+# This module will set the following variables in your project:
 #
-# ::
+# ``ALSA_FOUND``
+#   true if the ALSA headers and libraries were found
+# ``ALSA_INCLUDE_DIRS``
+#   the directory containing the ALSA headers
+# ``ALSA_LIBRARIES``
+#   ALSA libraries to be linked.
 #
-#  ALSA_INCLUDE_DIR - where to find asoundlib.h, etc.
-#  ALSA_LIBRARY - the asound library
-#  ALSA_VERSION_STRING - the version of alsa found (since CMake 2.8.8)
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set.
+#
+# ``ALSA_INCLUDE_DIR``
+#   the directory containing the ALSA headers
+# ``ALSA_LIBRARY``
+#   the path to the ALSA ASound library
 
 #=
 # Copyright 2009-2011 Kitware, Inc.
 # Copyright 2009-2011 Philip Lowman 
+# Copyright 2016 Raumfeld
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -58,8 +72,19 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(ALSA
   VERSION_VAR ALSA_VERSION_STRING)
 
 if(ALSA_FOUND)
-  set( ALSA_LIBRARIES ${ALSA_LIBRARY} )
-  set( ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR} )
+  set(ALSA_VERSION ${ALSA_VERSION_STRING})
+  set(ALSA_LIBRARIES ${ALSA_LIBRARY})
+  set(ALSA_INCLUDE_DIRS ${ALSA_INCLUDE_DIR})
+
+  if(NOT TARGET ALSA::ASound)
+add_library(ALSA::ASound UNKNOWN IMPORTED)
+set_target_properties(ALSA::ASound PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+  IMPORTED_LOCATION "${ALSA_LIBRARY}"
+  INTERFACE_INCLUDE_DIRECTORIES "${ALSA_INCLUDE_DIRS}"
+  INTERFACE_LIBRARIES "${ALSA_LIBRARY}"
+  )
+  endif()
 endif()
 
 mark_as_advanced(ALSA_INCLUDE_DIR ALSA_LIBRARY)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 043b757..26b0cee 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1355,6 +1355,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 endif()
   endif()
 
+  if(CMake_TEST_FindALSA)
+add_subdirectory(FindALSA)
+  endif()
+
   if(CMake_TEST_FindBoost)
 add_subdirectory(FindBoost)
   endif()
diff --git a/Tests/FindALSA/CMakeLists.txt b/Tests/FindALSA/CMakeLists.txt
new file mode 100644
index 000..891f7a4
--- /dev/null
+++ b/Tests/FindALSA/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindALSA.Test COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/FindALSA/Test"
+  "${CMake_BINARY_DIR}/Tests/FindALSA/Test"
+  ${build_generator_args}
+  --build-project TestFindALSA
+  --build-options ${build_options}
+  --test-command ${CMAKE_CTEST_COMMAND} -V -C $
+  )
diff --git a/Tests/FindALSA/Test/CMakeLists.txt 
b/Tests/FindALSA/Test/CMakeLists.txt
new file mode 100644
index 000..2dae457
--- /dev/null
+++ b/Tests/FindALSA/Test/CMakeLists.txt
@@ -0,0 +1,16 @@
+cmake_minimum_required(VERSION 3.4)
+project(TestFindALSA C)
+include(CTest)
+
+find_package(ALSA REQUIRED)
+
+add_definitions(-DCMAKE_ASOUNDLIB_EXPECTED_VERSION=\"${ALSA_VERSION}\")
+
+add_executable(test_tgt main.c)
+target_link_libraries(test_tgt ALSA::ASound)
+add_test(NAME test_tgt COMMAND test_tgt)
+
+add_executable(test_vars main.c)
+target_include_directories(test_vars PRIVAT

Re: [cmake-developers] [patch] New find module FindXalanC

[Brad King]

On 01/19/2016 11:39 AM, Roger Leigh wrote:
> Merged into next from the staging branch "xalanc" for review and 
> testing.  Includes a couple of unit tests to validate.  Since it depends 
> on XercesC, I hope what I've done here for the imported and non-imported 
> target cases is OK.

Thanks.  Please also add a Help/release/dev/FindXalanC.rst release note
that mentions the new module.

I've updated one of our nightly testing machines to enable the new test
for this topic.

> +find_package(XercesC 3.0.0 REQUIRED)

Please add a comment here justifying use of this particular version number.
Explain that/why it does not depend on the XalanC version requested.

> +# ``XalanC_LIBRARIES``
> +# Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also
> +# required

Our convention is to include dependencies in reported values automatically.
See FindPNG for its use of ZLIB, for example.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015928]: FindwxWidgets Fails

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15928 
== 
Reported By:deaths_soul
Assigned To:
== 
Project:CMake
Issue ID:   15928
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-19 11:47 EST
Last Modified:  2016-01-19 11:47 EST
== 
Summary:FindwxWidgets Fails
Description: 
When I try to use FindwxWidgets in CMake 3.4.1, I keep getting the following
error:
CMake Error at /usr/share/cmake/Modules/FindwxWidgets.cmake:870 (message):
   wxWidgets wx/version.h file not found in
  
/home/User/Code/wxWidgets/win_build32/lib/wx/include/i686-w64-mingw32-msw-unicode-static-3.0;/home/User/Code/wxWidgets/include.

Even though the file exists and I've even made a symlink in the other location
to make sure. In either case, I get that error. However, if I downgrade to CMake
3.3.2, everything works as it should.

The full path to wx/version.h is /home/User/Code/wxWidgets/include/wx/version.h.

In CMakeCache.txt, the _filename variable is set as follows:
_filename:FILEPATH=_filename-NOTFOUND

It's set to this value in both the CMakeCache.txt for 3.3.2 and 3.4.1. In
testing, I even deleted the working directory and started from a clean slate and
the issue still occurred with 3.4.1.

This is under Fedora 23 and cross-compiling using MinGW. The wxWidgets library
is self-compiled.

CMAKE_FIND_ROOT_PATH is set to usr/x86_64-w64-mingw32/sys-root/mingw or
/usr/i686-w64-mingw32/sys-root/mingw depending on which architecture I'm
building for. I use a mixture of libraries from the repos and self-built,
though.

CMAKE_FIND_ROOT_PATH_MODE_INCLUDE is set to ONLY.

Manually passing -D_filename=/home/User/Code/wxWidgets/include/wx/version.h when
I run the CMake configuration fixes the issue.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-19 11:47 deaths_soulNew 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] [patch] New find module FindXalanC

[Roger Leigh]

Merged into next from the staging branch "xalanc" for review and 
testing.  Includes a couple of unit tests to validate.  Since it depends 
on XercesC, I hope what I've done here for the imported and non-imported 
target cases is OK.


I've tested on Linux and Windows.


Regards,
Roger


--

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] Adding Swift support to CMake for Linux/Makefiles

[Brad King]

On 01/18/2016 01:51 PM, Eric Wing wrote:
> So the good news is I have a basic add_executable working with Swift
> on Linux via the Makefile generator.
> 
> It works with all Swift files, or intermixed C+Swift files. Bridging
> header is also supported.

Great!

> - I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
> couldn’t figure out what was providing the ‘-I’ flag for include
> paths. Rules like this still need to be rewritten for Swift.

Try adding to CMakeSwiftInformation:

 set(CMAKE_INCLUDE_FLAG_Swift -I)

> - TODO: I need to look at Swift's DEFINE system.

Yes.  After we get things building correctly the first time then we'll
also need to see about adding needed dependencies to the build system.

> - Note: The new file is Linux-unknown-Swift.cmake. When I compile
> Swift myself, there is no company or organization identifier (swift
> --version) unlike the one Apple ships with Xcode, and CMake refers to
> the identifier as ‘unknown’. I made the file reflect this, but maybe
> we should rename this later (maybe Swift_org).

In an earlier Swift thread there was discussion about the name of the
compiler id and ``Apple`` was chosen because that is the vendor of
their version.  We definitely need to choose an id besides "unknown"
for this.  Perhaps ``SwiftOrg``?  Also, we need a good way to check
the id.  We could use `--version` if necessary but do we know whether
the language provides any kind of identifier for code to use for
conditional compilation?

> - To answer your question about whether ‘swift’ instead of ’swiftc’
> can be used for linking, I think the answer is yes, but I have been
> unable to figure out the correct incantation.

Okay.  Let's go with the ``c`` hack until we
know more.  I'd prefer not to have to expose a separate setting for
the link driver only to remove it later.

> - Swift Standard (or Core) Libraries: Swift comes with multiple
> standard libraries.
[snip]
> I think CMake should provide some variables to the full paths to
> these libraries since users like me will want to refer to them.

Perhaps, but we currently don't do that for any other languages.
We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES
listing directories that may contain the standard libraries.
This is the same as the information needed to use the C linker
to mix languages that we previously discussed trying to extract
for Swift.

-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] [PATCH] Added FILTER subcommand to list command

[CHEVRIER, Marc]

I am in favour to use FILTER keyword and named arguments for filter behaviour. 
I think this approach is more elegant and also more flexible for any future 
enhancements.



On 19/01/16 16:43, "cmake-developers on behalf of Brad King" 
 wrote:

>On 01/16/2016 12:10 PM, Ashley Whetter wrote:
>> In response to issue 0003986, I've implemented a FILTER subcommand to the 
>> "list"
>> command that filters a list using a regular expression.
>
>Nice work.  The change looks good except I'd like to bikeshed the name
>of the option.  This is the first list() API that will use a regular
>expression as an argument, so I think "REGEX" should appear in the
>name, e.g. "FILTER_REGEX".  Also the name should clarify whether the
>filter result includes or excludes the matches.  Perhaps
>
> list(FILTER_REGEX_INCLUDE  )
>
>?  Alternatively the name could still be "FILTER" and there could
>be named arguments to control the rest of the details.  I have no
>preference but would welcome other opinions.
>
>Thanks,
>-Brad
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

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] [PATCH] Now prints line number of cache parse error

[Brad King]

On 01/17/2016 05:09 PM, Ashley Whetter wrote:
> To fix issue 11109, this patch implements the printing of the line number of 
> the
> CMakeCache.txt file that causes a parse error when an error occurs.

Thanks!  Applied with minor fix to the test suite:

 Print line number of cache parse errors (#11109)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77cd74a3

-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] Access output from CheckCXXSourceRuns and CheckCSourceRuns

[Brad King]

On 01/18/2016 01:32 PM, Harry Mallon wrote:
> https://github.com/Kitware/CMake/pull/209
> This passes through the output of the run (as well as the return value)
> so that users can access any output without using try_run.

Thanks.  The signature of the macro takes a variable for the return value
to be stored.  We need something similar to control the name of the variable
used to store the output.  This could either be done with an optional/named
argument or simply by documenting that the output will come in `_OUTPUT`.
We also need to define what happens when the check has already been run.
The normal `` result is cached to prevent repeat runs of the check.
I don't think we can reasonably cache the entire output of the run and
provide it on later re-runs of CMake when the check does not actually run.

OTOH your use case for extracting versions may have other solutions.
We generally try to avoid try_run because it only works when the toolchain
targets the host architecture and so does not work when cross compiling
in general.  Look at what Modules/CMakeDetermineCompilerId.cmake does to
extract the compiler id and version information.  It also leaves files
in build trees under CMakeFiles/${CMAKE_VERSION}/CompilerIdC that you
can see.  Basically it encodes the needed information in strings that
can be extracted from the binaries without running them.

-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][PATCH] fix create_javah on Windows

[Brad King]

On 01/19/2016 03:58 AM, CHEVRIER, Marc wrote:
> Attached is a patch fixing erroneous handling of CLASSPATH
> Update tests accordingly.

Thanks, applied:

 UseJava: Fix create_javah CLASSPATH handling on Windows
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18c3714f

-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] [PATCH] Added FILTER subcommand to list command

[Brad King]

On 01/16/2016 12:10 PM, Ashley Whetter wrote:
> In response to issue 0003986, I've implemented a FILTER subcommand to the 
> "list"
> command that filters a list using a regular expression.

Nice work.  The change looks good except I'd like to bikeshed the name
of the option.  This is the first list() API that will use a regular
expression as an argument, so I think "REGEX" should appear in the
name, e.g. "FILTER_REGEX".  Also the name should clarify whether the
filter result includes or excludes the matches.  Perhaps

 list(FILTER_REGEX_INCLUDE  )

?  Alternatively the name could still be "FILTER" and there could
be named arguments to control the rest of the details.  I have no
preference but would welcome other opinions.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Now prints warning when --build is not honored

[Brad King]

On 01/17/2016 11:35 AM, Ashley Whetter wrote:
> As per issue 12641, this patch means that a warning is given when the 
> "--build"
> option is ignored.

Thanks for working on this.

> I'm not sure if you'd want a different error message here.

Ideally all unused arguments would get a warning but that will take significant
refactoring of how arguments are stored and passed around internally.

> I feel like it might be better to print something about the fact that 
> "--build"
> should be used after the binary tree has been generated,
> but I can't think of a good way to word it.

How about:

  Ignoring option '--build' because it is meant to be used only
  to drive an already-generated project build system.

?

Please also add a test somewhere in Tests/RunCMake for this.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015927]: Escape semicolon "; " in CMake/CTest variables?

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15927 
== 
Reported By:Gehua Yang
Assigned To:
== 
Project:CMake
Issue ID:   15927
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-19 10:07 EST
Last Modified:  2016-01-19 10:07 EST
== 
Summary:Escape semicolon ";" in CMake/CTest variables?
Description: 
My CMake-Controlled private build depends on a couple external libraries.  On
Windows, the build needs to find the dll  files of external libraries in order
to run the automated tests.   The solution I came up with is to add those
folders to the PATH environment variable for the build.  Here is what I did in
the CTest script (using CMake 3.4.1 for Windows):

SET(MYPATH
"$ENV{PATH}\;C:\\Gehua\\Code\\tbb\\tbb43_20150611oss\\bin\\intel64\\vc14")
# set any extra envionment variables here
#   a. TBB path is needed to run tests
#   b. Use the "true" command-line plink for git's ssh use.
SET (CTEST_ENVIRONMENT
  "GIT_SSH=c:\\Program Files (x86)\\PuTTY\\plink.exe"
  "PATH=${MYPATH}"
  )
MESSAGE(STATUS "env=${CTEST_ENVIRONMENT}")

Here is the output from running the build from the code above:

-- env=GIT_SSH=c:\Program Files
(x86)\PuTTY\plink.exe;PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program
Files\Broadcom\Broadcom 802.11 Network Adapter;C:\Program Files (x86)\Intel\iCLS
Client\;C:\Program Files\Intel\iCLS
Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;%USERPROFILE%\.dnx\bin;C:\Program
Files (x86)\Skype\Phone\;C:\Program Files\IDM Computer
Solutions\UltraCompare;C:\Program Files\IDM Computer
Solutions\UltraFinder\\;C:\Gehua\Code\tbb\tbb43_20150611oss\bin\intel64\vc14


But this change does NOT work for the tests.  The tests failed without
execution.  I suspected that it still did not find the depending dll files.  So
I added the following code in a simple test file:

  std::cout << "env PATH=" << getenv ("PATH") << '\n';
  std::cout << "env GIT_SSH=" << getenv ("GIT_SSH") << '\n';

The output is :

env PATH=C:\ProgramData\Oracle\Java\javapath
env GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe


As one can see, The PATH variable content was truncated at the semicolon mark
(";").  It is not surprising outcome as CMake use semicolon as delimiter of list
elements.  But in this particular case,  I am seeking for a way to escape the
semicolons so that CMake/CTest treats it as an integral part of the string.  Is
there a way to do it? 

Steps to Reproduce: 
SET(MYPATH
"$ENV{PATH}\;C:\\Gehua\\Code\\tbb\\tbb43_20150611oss\\bin\\intel64\\vc14")
# set any extra envionment variables here
#   a. TBB path is needed to run tests
#   b. Use the "true" command-line plink for git's ssh use.
SET (CTEST_ENVIRONMENT
  "GIT_SSH=c:\\Program Files (x86)\\PuTTY\\plink.exe"
  "PATH=${MYPATH}"
  )
MESSAGE(STATUS "env=${CTEST_ENVIRONMENT}")


But the result is:
PATH=C:\ProgramData\Oracle\Java\javapath
GIT_SSH=c:\Program Files (x86)\PuTTY\plink.exe
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-19 10:07 Gehua Yang 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] [CMake 0015926]: FindCURL.cmake exposed variables are empty

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15926 
== 
Reported By:Lars Kühne
Assigned To:
== 
Project:CMake
Issue ID:   15926
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-19 08:52 EST
Last Modified:  2016-01-19 08:52 EST
== 
Summary:FindCURL.cmake exposed variables are empty
Description: 
The FindCURL.cmake module exposes variables CURL_INCLUDE_DIRS and
CURL_LIBRARIES, among others. These variables are empty, even though CURL_FOUND
is true. Internally, the FindCURL.cmake script uses CURL_INCLUDE_DIR and
CURL_LIBRARY variables. These are set correctly to the found locations on my
system. Using these instead of the variables documented in the reference and at
the beginning of the script works.

Steps to Reproduce: 
find_package(CURL REQUIRED)

message(CURL_FOUND)  # true on my system

message(${CURL_INCLUDE_DIRS})  # this fails
message(${CURL_LIBRARIES}) # this too

message(${CURL_INCLUDE_DIR})   # this works
message(${CURL_LIBRARY})   # this too
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-19 08:52 Lars Kühne 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] [CMAKE][PATCH] fix create_javah on Windows

[CHEVRIER, Marc]

Hi,

Attached is a patch fixing erroneous handling of CLASSPATH parameter for 
function create_javah (module UseJava).
Update tests accordingly.

Marc



0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch
Description: 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.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