[cmake-developers] [Patch] FindPkgConfig: optionally create imported target for the found libraries

2016-05-11 Thread Rolf Eike Beer 
It has always nagged me that the FindPkgConfig module requires people to use 
link_directories(). Now I created a new optional mode for pkg_check_modules() 
and pkg_search_modules() which will search the absolute paths of the libraries 
that are returned by pkg-config, and create an imported target from that 
information that also contains defines and include directories. It restricts 
searching to the directories returned by pkg-config, if none are given the 
normal search rules are used. I have manually tested this and it seems to 
work. Please have a look and tell me if I have missed something before I put 
this into next.

Greetings,

Eike

From 352e6b2733995dc121fe5d80d1183fe372522124 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer 
Date: Wed, 11 May 2016 23:45:26 +0200
Subject: [PATCH] FindPkgConfig: optionally create imported target for the
 found libraries

---
 Modules/FindPkgConfig.cmake | 81 +
 1 file changed, 74 insertions(+), 7 deletions(-)

diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 447c526..fd71a7a 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -16,6 +16,7 @@
 # Copyright 2006-2014 Kitware, Inc.
 # Copyright 2014  Christoph Grüninger 
 # Copyright 2006  Enrico Scholz 
+# Copyright 2016  Rolf Eike Beer 
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -119,11 +120,12 @@ macro(_pkgconfig_invoke_dyn _pkglist _prefix _varname 
cleanup_regexp)
 endmacro()
 
 # Splits given arguments into options and a package list
-macro(_pkgconfig_parse_options _result _is_req _is_silent _no_cmake_path 
_no_cmake_environment_path)
+macro(_pkgconfig_parse_options _result _is_req _is_silent _no_cmake_path 
_no_cmake_environment_path _imp_target)
   set(${_is_req} 0)
   set(${_is_silent} 0)
   set(${_no_cmake_path} 0)
   set(${_no_cmake_environment_path} 0)
+  set(${_imp_target} 0)
   if(DEFINED PKG_CONFIG_USE_CMAKE_PREFIX_PATH)
 if(NOT PKG_CONFIG_USE_CMAKE_PREFIX_PATH)
   set(${_no_cmake_path} 1)
@@ -147,6 +149,9 @@ macro(_pkgconfig_parse_options _result _is_req _is_silent 
_no_cmake_path _no_cma
 if (_pkg STREQUAL "NO_CMAKE_ENVIRONMENT_PATH")
   set(${_no_cmake_environment_path} 1)
 endif()
+if (_pkg STREQUAL "IMPORTED_TARGET")
+  set(${_imp_target} 1)
+endif()
   endforeach()
 
   set(${_result} ${ARGN})
@@ -154,6 +159,7 @@ macro(_pkgconfig_parse_options _result _is_req _is_silent 
_no_cmake_path _no_cma
   list(REMOVE_ITEM ${_result} "QUIET")
   list(REMOVE_ITEM ${_result} "NO_CMAKE_PATH")
   list(REMOVE_ITEM ${_result} "NO_CMAKE_ENVIRONMENT_PATH")
+  list(REMOVE_ITEM ${_result} "IMPORTED_TARGET")
 endmacro()
 
 # Add the content of a variable or an environment variable to a list of
@@ -181,8 +187,60 @@ function(_pkgconfig_add_extra_path _extra_paths_var _var)
   set(${_extra_paths_var} ${${_extra_paths_var}} PARENT_SCOPE)
 endfunction()
 
+# scan the LDFLAGS returned by pkg-config for library directories and
+# libraries, figure out the absolute paths of that libraries in the
+# given directories, and create an imported target from them
+function(_pkg_create_imp_target _prefix _no_cmake_path 
_no_cmake_environment_path)
+  unset(_libs)
+  unset(_find_opts)
+
+  # set the options that are used as long as the .pc file does not provide a 
library
+  # path to look into
+  if(_no_cmake_path)
+set(_find_opts "NO_CMAKE_PATH")
+  endif()
+  if(_no_cmake_environment_path)
+set(_find_opts "${_find_opts} NO_CMAKE_ENVIRONMENT_PATH")
+  endif()
+
+  foreach (flag IN LISTS ${_prefix}_LDFLAGS)
+if (flag MATCHES "^-L(.*)")
+  # only look into the given paths from now on
+  set(_find_opts "HINTS ${${CMAKE_MATCH_1}} NO_DEFAULT_PATH")
+  continue()
+endif()
+if (flag MATCHES "^-l(.*)")
+  set(_pkg_search "${CMAKE_MATCH_1}")
+else()
+  continue()
+endif()
+
+find_library(${_prefix}-${CMAKE_MATCH_1}
+ NAMES ${CMAKE_MATCH_1}
+ ${_find_opts})
+list(APPEND _libs "${${_prefix}-${CMAKE_MATCH_1}}")
+  endforeach()
+
+  # only create the target if it is linkable, i.e. no executables
+  if (NOT TARGET PkgConfig::${_prefix}
+  AND ( ${_prefix}_INCLUDE_DIRS OR _libs OR ${_prefix}_CFLAGS_OTHER ))
+add_library(PkgConfig::${_prefix} INTERFACE IMPORTED)
+if(${_prefix}_INCLUDE_DIRS)
+  set_target_properties(PkgConfig::${_prefix} PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${${_prefix}_INCLUDE_DIRS}")
+endif()
+if(_libs)
+  set_target_properties(PkgConfig::${_prefix} PROPERTIES
+INTERFACE_LINK_LIBRARIES "${_libs}")
+endif()
+if(${_prefix}_CFLAGS_OTHER)
+  set_property(TARGET PkgConfig::${_prefix} PROPERTY 
INTERFACE_COMPILE_OPTIONS "${${_prefix}_CFLAGS_OTHER}")
+endif()
+  endif()

Re: [cmake-developers] CLang error when building iOS bundle

2016-05-11 Thread Gregor Jasny via cmake-developers 
Hello,

On 11/05/16 21:22, Roman Wüger wrote:
> I got the following error when linking the iOS bundle:
> 
> clang: error: cannot specify -o when generating multiple output files
> 
> I didn’t found anything about the error in the internet, so maybe someone
> has already solved such error?
> 
> Does any one have a hint what could be wrong?

I cannot see any suspicious things, either (besides that -arch armv7 is
listed twice). I would suggest you create a new user on the machine and
try there. Or you could remove ~/Library/Developer/Xcode/DerivedData first.

Thanks,
Gregor
-- 

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] FindBoost does not detect absence of header file

2016-05-11 Thread rleigh 

On 2016-05-11 19:30, Chuck Atkins wrote:

I guess it doesn't really matter but for the libraries that don't have
a single include header, should you be using these instead:

* container/container_fwd.hpp
* exception/all.hpp
* filesystem.hpp
* math_fwd.hpp (instead of math/quaternion.hpp)
* system/config.hpp
* type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of
specific headers.


Thanks for taking a look and making the suggestions.  I'll certainly 
update some of these.  However, note that for some of these (e.g. 
exception, filesystem), that common header didn't exist in earlier 
releases and so was deliberately not used; in these cases I picked a 
common header which is present in *all* Boost releases, back to 1.33 
except for components which were introduced in later releases.  
filesystem.hpp was introduced after the initial release with filesytem, 
likewise exception/all.hpp for exception.



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] [PATCH] FindBoost does not detect absence of header file

2016-05-11 Thread Chuck Atkins 
I guess it doesn't really matter but for the libraries that don't have a
single include header, should you be using these instead:

   - container/container_fwd.hpp
   - exception/all.hpp
   - filesystem.hpp
   - math_fwd.hpp (instead of math/quaternion.hpp)
   - system/config.hpp
   - type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of specific
headers.

- Chuck

On Wed, May 11, 2016 at 10:38 AM,  wrote:

> On 2016-04-12 11:22, Joachim Wuttke wrote:
>
>> FindBoost does not detect absence of header files.
>>
>> To be specific: Run the following under cmake version 3.5.1:
>>
>> set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
>> set(Boost_USE_STATIC_LIBS OFF)
>> set(Boost_USE_MULTITHREADED ON)
>> set(Boost_USE_STATIC_RUNTIME OFF)
>> add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
>> #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
>> auto-linked libraries
>> if(WIN32)
>> set(boost_libraries_required date_time chrono program_options zlib
>> bzip2 iostreams system filesystem regex thread)
>> else()
>> set(boost_libraries_required date_time chrono program_options
>> iostreams system filesystem regex thread)
>> endif()
>> find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED)
>> message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
>> message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
>> message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
>>
>> It will pass, even if files like /usr/include/boost/date_time.hpp  are
>> removed
>> from the system.
>>
>
> Attached is a patch to add this extra checking.
>
> For each library component, there is a corresponding header which has been
> present in all versions of boost to date which provide the library; the
> list used to validate this is also attached.  I have also validated that
> each component works with find_package for Boost 1.58 and 1.60.
>
> If your system contains both the libraries and headers, then FindBoost
> will behave exactly as before.  But if you have the libraries without the
> headers, FindBoost will now fail, rather than passing and then having the
> build subsequently fail when it tries to use the nonexistent headers.  So
> it's essentially adding an additional header check per component, which
> will identify situations where the user has an incomplete Boost
> installation e.g. no all the -dev packages are installed.
>
> I can merge this into next for testing, but if anyone wanted to have an
> initial play with it to verify that it's still functional and that the
> approach is sound, I can wait off for now.
>
>
> 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
>
-- 

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] CLang error when building iOS bundle

2016-05-11 Thread Roman Wüger 
Hello list,

 

I got the following error when linking the iOS bundle:

clang: error: cannot specify -o when generating multiple output files

 

I didn’t found anything about the error in the internet, so maybe someone
has already solved such error?

Does any one have a hint what could be wrong?

 

Thank you very much in advance

 

Best Regards

Roman

 

P.S.: Here is the last output:

 

CompileC
/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i
OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects
-normal/armv7/main.o appQml/main.cpp normal armv7 c++
com.apple.compilers.llvm.clang.1_0.compiler

cd
/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i
OS-debug/source

export LANG=en_US.US-ASCII

export
PATH="/Applications/Xcode_7_3_1.app/Contents/Developer/Platforms/iPhoneOS.pl
atform/Developer/usr/bin:/Applications/Xcode_7_3_1.app/Contents/Developer/us
r/bin::/bin:/opt/Externals:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt
/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/
Server.app/Contents/ServerRoot/usr/sbin"

 
/Applications/Xcode_7_3_1.app/Contents/Developer/Toolchains/XcodeDefault.xct
oolchain/usr/bin/clang -x c++ -arch armv7 -fmessage-length=233
-fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0
-fcolor-diagnostics -std=c++11 -stdlib=libc++ -Wno-trigraphs
-fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes
-Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual
-Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch
-Wno-unused-function -Wno-unused-label -Wno-unused-parameter
-Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized
-Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion
-Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion
-Wno-enum-conversion -Wno-shorten-64-to-32 -Wno-newline-eof
-Wno-c++11-extensions -DCMAKE_INTDIR=\"Debug-iphoneos\" -DQT_QML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_WIDGETS_LIB
-DPLATFORM_IS_IOS -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII
-DQT_NO_CAST_TO_BYTEARRAY -DWSD_HAS_GENERIC_HIGHLIGHTER -DNOMINMAX
-DQT_XML_LIB -isysroot
/Applications/Xcode_7_3_1.app/Contents/Developer/Platforms/iPhoneOS.platform
/Developer/SDKs/iPhoneOS9.3.sdk -fstrict-aliasing -Wdeprecated-declarations
-Winvalid-offsetof -miphoneos-version-min=9.3 -Wno-sign-conversion
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/build/bin/Debug/include
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/build/appQml
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/appQml
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/build/cmake/cmake_wsd
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/build/cmake -I/opt/Qt/5.6/ios/include
-I/opt/Qt/5.6/ios/include/QtWidgets -I/opt/Qt/5.6/ios/include/QtGui
-I/opt/Qt/5.6/ios/include/QtCore -I/opt/Qt/5.6/ios/mkspecs/macx-ios-clang
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/gtest/include
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/Screens
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/QmlTools
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/Tools
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/Utilities/libraries/GuiTools
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/Utilities/libraries/Tools
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/libraries/Utilities/libraries/QtTools
-I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos
-iOS-debug/source/interfaces
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreFoundation.framewo
rk/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreGraphics.framework
/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreText.framework/Hea
ders
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev
eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/Foundation.framework/H
eaders
-I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev

[cmake-developers] CMake 3.6 feature freeze on 2016-06-01

2016-05-11 Thread Brad King 
Hi Folks,

The feature freeze in 'master' for CMake 3.6 will be on June 1, 2016.
I may announce a freeze in 'next' sometime in the preceding week so
that we can get any remaining dashboard trouble cleaned up.

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] [PATCH] FindBoost does not detect absence of header file

2016-05-11 Thread rleigh 

On 2016-04-12 11:22, Joachim Wuttke wrote:

FindBoost does not detect absence of header files.

To be specific: Run the following under cmake version 3.5.1:

set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
#add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
auto-linked libraries
if(WIN32)
set(boost_libraries_required date_time chrono program_options zlib
bzip2 iostreams system filesystem regex thread)
else()
set(boost_libraries_required date_time chrono program_options
iostreams system filesystem regex thread)
endif()
find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} 
REQUIRED)

message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")

It will pass, even if files like /usr/include/boost/date_time.hpp  
are removed

from the system.


Attached is a patch to add this extra checking.

For each library component, there is a corresponding header which has 
been present in all versions of boost to date which provide the library; 
the list used to validate this is also attached.  I have also validated 
that each component works with find_package for Boost 1.58 and 1.60.


If your system contains both the libraries and headers, then FindBoost 
will behave exactly as before.  But if you have the libraries without 
the headers, FindBoost will now fail, rather than passing and then 
having the build subsequently fail when it tries to use the nonexistent 
headers.  So it's essentially adding an additional header check per 
component, which will identify situations where the user has an 
incomplete Boost installation e.g. no all the -dev packages are 
installed.


I can merge this into next for testing, but if anyone wanted to have an 
initial play with it to verify that it's still functional and that the 
approach is sound, I can wait off for now.



Regards,
RogerFrom 724084194b6be8b0a3fb752b265b140db79487f2 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 11 May 2016 10:55:51 +0100
Subject: [PATCH] FindBoost: Add checks for component-specific headers

This supplements the existing library checks, to
cater for the possibility that the libraries are
present but the headers are not.  This can happen
when the Boost collections is split up into
multiple packages and not all are installed,
and will avoid the checks silently passing when
the build would subsequently fail.
---
 Modules/FindBoost.cmake | 87 ++---
 1 file changed, 83 insertions(+), 4 deletions(-)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 3d573b8..e268953 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -310,7 +310,7 @@ macro(_Boost_ADJUST_LIB_VARS basename)
   set(Boost_${basename}_LIBRARIES ${Boost_${basename}_LIBRARY_RELEASE} )
 endif()
 
-if(Boost_${basename}_LIBRARY)
+if(Boost_${basename}_LIBRARY AND Boost_${basename}_HEADER)
   set(Boost_${basename}_FOUND ON)
 endif()
 
@@ -522,7 +522,9 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
   #
   # The output may be added in a new block below.  If it's the same as
   # the previous release, simply update the version range of the block
-  # for the previous release.
+  # for the previous release.  Also check if any new components have
+  # been added, and add any new components to
+  # _Boost_COMPONENT_HEADERS.
   #
   # This information was originally generated by running
   # BoostScanDeps.cmake against every boost release to date supported
@@ -740,6 +742,67 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 endfunction()
 
 #
+# Get component headers.  This is the primary header (or headers) for
+# a given component, and is used to check that the headers are present
+# as well as the library itself as an extra sanity check of the build
+# environment.
+#
+# component - the component to check
+# _hdrs
+#
+function(_Boost_COMPONENT_HEADERS component _hdrs)
+  # Note: new boost components will require adding here.  The header
+  # must be present in all versions of Boost providing a library.
+  set(_Boost_ATOMIC_HEADERS  "boost/atomic.hpp")
+  set(_Boost_CHRONO_HEADERS  "boost/chrono.hpp")
+  set(_Boost_CONTAINER_HEADERS   "boost/container/adaptive_pool.hpp")
+  set(_Boost_CONTEXT_HEADERS "boost/context/all.hpp")
+  set(_Boost_COROUTINE_HEADERS   "boost/coroutine/all.hpp")
+  set(_Boost_EXCEPTION_HEADERS   "boost/exception/exception.hpp")
+  set(_Boost_DATE_TIME_HEADERS   "boost/date_time/date.hpp")
+  set(_Boost_FILESYSTEM_HEADERS  "boost/filesystem/path.hpp")
+  set(_Boost_GRAPH_HEADERS   "boost/graph/adjacency_list.hpp")
+

Re: [cmake-developers] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

2016-05-11 Thread Harry Mallon 
Hi Domen,

That is infinitely simpler. Looks like a good addition to me.

Thanks,
Harry


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=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]

On 11 May 2016, at 10:33, Domen Vrankar 
> wrote:



0001-CPack-RPM-release-dist-tag-support.patch
Description: 0001-CPack-RPM-release-dist-tag-support.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

Re: [cmake-developers] Make CPACK_RPM_PACKAGE_RELEASE match Fedora/RHOS/CentOS recommended behaviour

2016-05-11 Thread Domen Vrankar 
Sorry for the late reply.

Here is another go. I have added a 3rd variable but I think it means that
> current behaviour is continued and your input (thanks Dolf and Romen) has
> been addressed.
>
> https://github.com/hm1992/CMake/commit/2f54442388ab767f60fcb8cde1db2236ae535080
>

I'm somewhat reluctant to add yet another CPACK_RPM_* variable to an
already long list as it doesn't add much value - RPMBUILD-DEFAULT
functionality could just as easily be added to CPACK_RPM_DIST variable
without breaking the back compatibility.

I took a better look at the documentation that you were referring to (
https://fedoraproject.org/wiki/Packaging:DistTag) and noticed this section:

   - You must not override the variables for %{dist} (or any of the related
   variables).
   - You must not hardcode a value for %{dist} (or any of the related
   variables) in your spec.
   - You must not hardcode a dist tag in the spec: *BAD:* Release: 1.fc20
   *GOOD:* Release: 1%{?dist}
   - You cannot put any sort of "tagging" in %{dist} (or any of the related
   variables). %{dist} (and its related variables) exist ONLY to define the
   distribution that a package was built against.

It would seem that overriding dist tag is unsupported and prohibited.

I've changed the patch with that in mind. Would the attached patch be OK
for you?
Thanks,
Domen
From 1091950f7ecabcaf283afbf3e36e357d1cd5b00b Mon Sep 17 00:00:00 2001
From: Harry Mallon 
Date: Wed, 11 May 2016 11:21:11 +0200
Subject: [PATCH 1/1] CPack/RPM release dist tag support

Some Linux distros require Release tag
to be set to .
---
 Modules/CPackRPM.cmake | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 768d64f..330fc1e 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -80,10 +80,27 @@
 #
 #  This is the numbering of the RPM package itself, i.e. the version of the
 #  packaging and not the version of the content (see
-#  CPACK_RPM_PACKAGE_VERSION). One may change the default value if the
-#  previous packaging was buggy and/or you want to put here a fancy Linux
+#  :variable:`CPACK_RPM_PACKAGE_VERSION`). One may change the default value if
+#  the previous packaging was buggy and/or you want to put here a fancy Linux
 #  distro specific numbering.
 #
+# .. note::
+#
+#  This is the string that goes into the RPM ``Release:`` field. Some distros
+#  (e.g. Fedora, CentOS) require ``1%{?dist}`` format and not just a number.
+#  ``%{?dist}`` part can be added by setting :variable:`CPACK_RPM_PACKAGE_RELEASE_DIST`.
+#
+# .. variable:: CPACK_RPM_PACKAGE_RELEASE_DIST
+#
+#  The dist tag that is added  RPM ``Release:`` field.
+#
+#  * Mandatory : NO
+#  * Default   : OFF
+#
+#  This is the reported ``%{dist}`` tag from the current distribution or empty
+#  ``%{dist}`` if RPM macro is not set. If this variable is set then RPM
+#  ``Release:`` field value is set to ``${CPACK_RPM_PACKAGE_RELEASE}%{?dist}``.
+#
 # .. variable:: CPACK_RPM_PACKAGE_LICENSE
 #
 #  The RPM package license policy.
@@ -1317,7 +1334,11 @@ function(cpack_rpm_generate_package)
   # This is the case when the packaging is buggy (not) the software :=)
   # If not set, 1 is a good candidate
   if(NOT CPACK_RPM_PACKAGE_RELEASE)
-set(CPACK_RPM_PACKAGE_RELEASE 1)
+set(CPACK_RPM_PACKAGE_RELEASE "1")
+  endif()
+
+  if(CPACK_RPM_PACKAGE_RELEASE_DIST)
+set(CPACK_RPM_PACKAGE_RELEASE "${CPACK_RPM_PACKAGE_RELEASE}%{?dist}")
   endif()
 
   # CPACK_RPM_PACKAGE_LICENSE
-- 
2.7.4

-- 

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 0016100]: Implicit link information parsing reads the wrong line from 'pathcc -v' output

2016-05-11 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16100 
== 
Reported By:Michał Górny
Assigned To:
== 
Project:CMake
Issue ID:   16100
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-05-11 03:22 EDT
Last Modified:  2016-05-11 03:22 EDT
== 
Summary:Implicit link information parsing reads the wrong
line from 'pathcc -v' output
Description: 
$ pathcc --version
PathScale EKOPath(tm) Compiler Suite: Version 6.0.779
Built on: 
Thread model: posix
GNU gcc compatible version 4.2.1
[...]

When CMake attempts to get ABI info from the compiler, it gets the following
output:

[2/2] Linking C executable cmTC_cfda2   

PathScale EKOPath(tm) Compiler Suite: Version 6.0.570   

Built on:   

Thread model: posix 

GNU gcc compatible version 4.2.1

/opt/ekopath/lib/6.0.570/x8664/ldfe -v -TARG:isa=x86_64
-TARG:processor=barcelona -TARG:sse=on -TARG:sse2=on -TARG:sse3=on
-TARG:ssse3=off -TARG:sse4a=off -TARG:sse4_1=off -TARG:sse4_2=off -TARG:avx=off
-TARG:avx2=off -TARG:avx512dq=off -TARG:avx512vl=off -TARG:avx512bw=off
-TARG:avx512er=off -TARG:avx512f=off -TARG:fma=off -TARG:fma4=off -TARG:xop=off
-TARG:aes=off -TARG:pclmul=off -TARG:3dnow=off -o cmTC_cfda2 -show
CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed -lgcc -lc -lmv
-lmpath -lm --no-as-needed -lpscrt -lc
/opt/ekopath/lib/6.0.570/x8664/../../../x8664/bin/ld
-L/opt/ekopath/lib/6.0.570/x8664/64/system-provided/
-L/opt/ekopath/lib/6.0.570/x8664/64/ -rpath=/opt/ekopath/lib/6.0.570/x8664/64/
--dynamic-linker=/lib64/ld-linux-x86-64.so.2 -melf_x86_64 --eh-frame-hdr -v -o
cmTC_cfda2 /opt/ekopath/lib/6.0.570/x8664/64/system-provided/crt1.o
/opt/ekopath/lib/6.0.570/x8664/64/system-provided/crti.o
/opt/ekopath/lib/6.0.570/x8664/64/crtbegin.o
CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed
-L/opt/ekopath/lib/6.0.570/x8664/64/ -lgcc /lib64/libc.so.6
/usr/lib64/libc_nonshared.a /lib64/ld-linux-x86-64.so.2
-L/opt/ekopath/lib/6.0.570/x8664/64/ -lmv -L/opt/ekopath/lib/6.0.570/x8664/64/
-lmpath /lib64/libm.so.6 /lib64/libmvec.so.1 --no-as-needed
/opt/ekopath/lib/6.0.570/x8664/64//libpscrt.a /lib64/libc.so.6
/usr/lib64/libc_nonshared.a /lib64/ld-linux-x86-64.so.2
/opt/ekopath/lib/6.0.570/x8664/64/crtend.o
/opt/ekopath/lib/6.0.570/x8664/64/system-provided/crtn.o
GNU ld (GNU Binutils) 2.25


Parsed C implicit link information from above output:   

  link line regex: [^( *|.*[/\])(ld|([^/\]+-)?ld|collect2)[^/\]*( |$)]
[...]
  link line: [/opt/ekopath/lib/6.0.570/x8664/ldfe -v -TARG:isa=x86_64
-TARG:processor=barcelona -TARG:sse=on -TARG:sse2=on -TARG:sse3=on
-TARG:ssse3=off -TARG:sse4a=off -TARG:sse4_1=off -TARG:sse4_2=off -TARG:avx=off
-TARG:avx2=off -TARG:avx512dq=off -TARG:avx512vl=off -TARG:avx512bw=off
-TARG:avx512er=off -TARG:avx512f=off -TARG:fma=off -TARG:fma4=off -TARG:xop=off
-TARG:aes=off -TARG:pclmul=off -TARG:3dnow=off -o cmTC_cfda2 -show
CMakeFiles/cmTC_cfda2.dir/CMakeCCompilerABI.c.o --as-needed -lgcc -lc -lmv
-lmpath -lm --no-as-needed -lpscrt -lc ]
[...]


However, this is not the correct line. ldfe is an internal helper, and it is
immediately followed by a call to 'ld' which has all the correct -L flags. As a
result, pathcc doesn't parse the correct data and doesn't determine multiarch
tuple on Debian.

Maybe it would be appropriate to not stop at the first line matching the regular
expression, and parse the last line matching it instead? This would prevent
CMake from parsing the wrapper when it's followed by an actual ld call.

Steps to Reproduce: 
1. install ekopath nightly (e.g.
http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-2016-04-28-installer.run),

2. attempt to build any CMake project.

On multiarch systems, find_library() won't be able to find any libraries. On
other systems, you can also see the problem when looking at CMakeOutput.log.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-05-11 03:22 Michał Górny   New Issue