[Cmake-commits] CMake branch, master, updated. v3.5.2-637-g27cda13

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  27cda1390ac0b927f4c573d8ab57e268d065b1b2 (commit)
  from  eb4f5104123a531bd49cb5834f3c66bb9e6aeeb6 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27cda1390ac0b927f4c573d8ab57e268d065b1b2
commit 27cda1390ac0b927f4c573d8ab57e268d065b1b2
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu May 12 00:01:11 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu May 12 00:01:11 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index ed8d6d9..a2178bf 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 5)
-set(CMake_VERSION_PATCH 20160511)
+set(CMake_VERSION_PATCH 20160512)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [CMake] AUTOMOC with files on different folders

[Hendrik Sattler]

Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios :
>Hi Attila,
>
>Thank you for your help. You are right, if I apply the following
>modifications it works indeed:
>
>set( proj_HEADER
>include/a.h
>)
>
>add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER})
>
>But now I got a second question. Why is adding the header files
>necessary?
>(Sorry the possibly naive question)
>
>I thought that adding the header files to the target was an
>anti-pattern (
>http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
>). Is it related to moc generating header files during the build? If so
>why
>is it not a problem when everything is on the same folder?

That same page has a Errata section at the end. 

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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1341-g232917e

[Domen Vrankar]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  232917e9e311ef44e472aa8b72bb4468f170e9e7 (commit)
   via  be6e9b384caf5c56887a8eb538fa4af7a9f74c02 (commit)
   via  74c32123440a8de96b25d038ec7ac447a78ee769 (commit)
  from  0823297845024f9fd0a47a3e8b7b5abbdd647100 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=232917e9e311ef44e472aa8b72bb4468f170e9e7
commit 232917e9e311ef44e472aa8b72bb4468f170e9e7
Merge: 0823297 be6e9b3
Author: Domen Vrankar 
AuthorDate: Wed May 11 18:35:19 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 18:35:19 2016 -0400

Merge topic 'cpack-deb-improvements' into next

be6e9b38 fixup! CPack/Deb test changes due to breaking changes
74c32123 fixup! CPack/Deb generation of DEBIAN/shlibs control file


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=be6e9b384caf5c56887a8eb538fa4af7a9f74c02
commit be6e9b384caf5c56887a8eb538fa4af7a9f74c02
Author: Domen Vrankar 
AuthorDate: Wed May 11 22:47:43 2016 +0200
Commit: Domen Vrankar 
CommitDate: Thu May 12 00:24:37 2016 +0200

fixup! CPack/Deb test changes due to breaking changes

diff --git a/Tests/RunCMake/CPack/CPackTestHelpers.cmake 
b/Tests/RunCMake/CPack/CPackTestHelpers.cmake
index aef1086..7bf42f9 100644
--- a/Tests/RunCMake/CPack/CPackTestHelpers.cmake
+++ b/Tests/RunCMake/CPack/CPackTestHelpers.cmake
@@ -9,6 +9,20 @@ function(run_cpack_test TEST_NAME types build)
 file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
 file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
 
+if(EXISTS 
"${RunCMake_SOURCE_DIR}/${TEST_TYPE}/${TEST_NAME}-Prerequirements.cmake")
+  
include("${RunCMake_SOURCE_DIR}/${TEST_TYPE}/${TEST_NAME}-Prerequirements.cmake")
+
+  set(FOUND_PREREQUIREMENTS false)
+  get_test_prerequirements("FOUND_PREREQUIREMENTS"
+  "${TEST_CONFIG_DIR}/${type}_config.cmake")
+
+  # skip the test if prerequirements are not met
+  if(NOT FOUND_PREREQUIREMENTS)
+message(STATUS "${TEST_NAME} - SKIPPED")
+return()
+  endif()
+endif()
+
 # execute cmake
 set(RunCMake_TEST_OPTIONS "-DGENERATOR_TYPE=${TEST_TYPE}")
 run_cmake(${TEST_NAME})
diff --git a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-Prerequirements.cmake 
b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-Prerequirements.cmake
new file mode 100644
index 000..b98065a
--- /dev/null
+++ b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-Prerequirements.cmake
@@ -0,0 +1,7 @@
+function(get_test_prerequirements found_var)
+  find_program(READELF_EXECUTABLE NAMES readelf)
+
+  if(READELF_EXECUTABLE)
+set(${found_var} true PARENT_SCOPE)
+  endif()
+endfunction()
diff --git a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-specifics.cmake 
b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-specifics.cmake
deleted file mode 100644
index b87b6ba..000
--- a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS-specifics.cmake
+++ /dev/null
@@ -1,5 +0,0 @@
-set(CPACK_PACKAGE_CONTACT "someone")
-set(CPACK_DEB_COMPONENT_INSTALL "ON")
-
-set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS "ON")
-set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS "ON")
diff --git 
a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-Prerequirements.cmake 
b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-Prerequirements.cmake
new file mode 100644
index 000..b98065a
--- /dev/null
+++ 
b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-Prerequirements.cmake
@@ -0,0 +1,7 @@
+function(get_test_prerequirements found_var)
+  find_program(READELF_EXECUTABLE NAMES readelf)
+
+  if(READELF_EXECUTABLE)
+set(${found_var} true PARENT_SCOPE)
+  endif()
+endfunction()
diff --git 
a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-specifics.cmake 
b/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-specifics.cmake
deleted file mode 100644
index 8b1cc37..000
--- a/Tests/RunCMake/CPack/DEB/DEB_GENERATE_SHLIBS_LDCONFIG-specifics.cmake
+++ /dev/null
@@ -1,6 +0,0 @@
-set(CPACK_PACKAGE_CONTACT "someone")
-set(CPACK_DEB_COMPONENT_INSTALL "ON")
-
-set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS "ON")
-set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS "ON")
-set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY ">=")
diff --git a/Tests/RunCMake/CPack/DEB/Helpers.cmake 
b/Tests/RunCMake/CPack/DEB/Helpers.cmake
index f490130..82dbd15 100644
--- a/Tests/RunCMake/CPack/DEB/Helpers.cmake
+++ b/Tests/RunCMake/CPack/DEB/Helpers.cmake
@@ -19,6 +19,10 @@ function(verifyDebControl FILE PREFIX VERIFY_FILES)
   endif()
 
   foreach(FILE_ IN LISTS VERIFY_FILES)

Re: [CMake] AUTOMOC with files on different folders

[Tiago Macarios]

Hi Attila,

Thank you for your help. You are right, if I apply the following
modifications it works indeed:

set( proj_HEADER
include/a.h
)

add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER})

But now I got a second question. Why is adding the header files necessary?
(Sorry the possibly naive question)

I thought that adding the header files to the target was an anti-pattern (
http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
). Is it related to moc generating header files during the build? If so why
is it not a problem when everything is on the same folder?

Tiago


On Wed, May 11, 2016 at 12:48 AM, Attila Krasznahorkay <
attila.krasznahor...@gmail.com> wrote:

> Hi Tiago,
>
> This is one of those cases when you have to declare the header files to
> add_library(...) as well. In that case AUTOMOC should work fine. At least
> it does for us, in a very similar setup.
>
>
> http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/graphics/VP1/VP1Gui/CMakeLists.txt
>
> Cheers,
> Attila
>
> > On 11 May 2016, at 07:14, Tiago Macarios 
> wrote:
> >
> > Hi,
> >
> > I am having trouble using AUTOMOC with a project where header files and
> source files are in different sub-directories. I wrote a detailed stack
> overflow question here:
> >
> http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders
> > and would really appreciate if someone could give me a couple of ideas
> to try out.
> >
> > Thanks,
> > Tiago
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[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] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning

[Gregor Jasny via CMake]

Hello,

On 11/05/16 09:25, Attila Krasznahorkay wrote:
> I'm a bit surprised by this. I had to explicitly tell CMake not to treat 
> includes coming from imported targets as system includes. Using this variable:
> 
> https://cmake.org/cmake/help/v3.0/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
> https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html
> 
> So I think this is in general a MacOS specific issue. I remember reading 
> about such issues a while ago. That CMake would not recognise that MacOS X's 
> clang would accept the -isystem argument out of the box.

This is a known bug: http://public.kitware.com/Bug/view.php?id=15687
Please look there for possible work-arounds.

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

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

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

[Gregor Jasny via CMake]

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

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

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

[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

Re: [CMake] [cmake-developers] [PATCH] FindBoost does not detect absence of header file

[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

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

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

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

[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-commits] CMake branch, next, updated. v3.5.2-1338-g0823297

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0823297845024f9fd0a47a3e8b7b5abbdd647100 (commit)
   via  062593273f4765e2948993992eaeac9acdab0e27 (commit)
  from  e3cf5a36e87691c9e806e8e2adcbb966735c1012 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0823297845024f9fd0a47a3e8b7b5abbdd647100
commit 0823297845024f9fd0a47a3e8b7b5abbdd647100
Merge: e3cf5a3 0625932
Author: Brad King 
AuthorDate: Wed May 11 15:19:56 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 15:19:56 2016 -0400

Merge topic 'clang-format-prep' into next

06259327 Tests: Wrap long comment lines in VSXaml test


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=062593273f4765e2948993992eaeac9acdab0e27
commit 062593273f4765e2948993992eaeac9acdab0e27
Author: Brad King 
AuthorDate: Wed May 11 15:16:04 2016 -0400
Commit: Brad King 
CommitDate: Wed May 11 15:16:04 2016 -0400

Tests: Wrap long comment lines in VSXaml test

Manually wrap the lines and remove literal tab characters.  This avoids
problems with incremental formatting by clang-format.

diff --git a/Tests/VSXaml/App.xaml.cpp b/Tests/VSXaml/App.xaml.cpp
index 2cb2b32..a187ed5 100644
--- a/Tests/VSXaml/App.xaml.cpp
+++ b/Tests/VSXaml/App.xaml.cpp
@@ -26,8 +26,9 @@ using namespace Windows::UI::Xaml::Navigation;
 // The Blank Application template is documented at 
http://go.microsoft.com/fwlink/?LinkId=234227
 
 /// 
-/// Initializes the singleton application object.  This is the first line of 
authored code
-/// executed, and as such is the logical equivalent of main() or WinMain().
+/// Initializes the singleton application object.  This is the first line of
+/// authored code executed, and as such is the logical equivalent of main()
+/// or WinMain().
 /// 
 App::App()
 {
@@ -36,8 +37,9 @@ App::App()
 }
 
 /// 
-/// Invoked when the application is launched normally by the end user. Other 
entry points
-/// will be used such as when the application is launched to open a specific 
file.
+/// Invoked when the application is launched normally by the end user.
+/// Other entry points will be used such as when the application is
+/// launched to open a specific file.
 /// 
 /// Details about the launch request and process.
 void 
App::OnLaunched(Windows::ApplicationModel::Activation::LaunchActivatedEventArgs^
 e)
@@ -101,9 +103,9 @@ void 
App::OnLaunched(Windows::ApplicationModel::Activation::LaunchActivatedEvent
 }
 
 /// 
-/// Invoked when application execution is being suspended. Application 
state is saved
-/// without knowing whether the application will be terminated or resumed with 
the contents
-/// of memory still intact.
+/// Invoked when application execution is being suspended.  Application state
+/// is saved without knowing whether the application will be terminated or
+/// resumed with the contents of memory still intact.
 /// 
 /// The source of the suspend request.
 /// Details about the suspend request.

---

Summary of changes:
 Tests/VSXaml/App.xaml.cpp |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)


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

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

[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-commits] CMake branch, next, updated. v3.5.2-1336-ge3cf5a3

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e3cf5a36e87691c9e806e8e2adcbb966735c1012 (commit)
   via  25845b10d8ef2ded79fadf7eb924609ff0b142ae (commit)
  from  824fa316be79bc424901f35176df3eaa087bc4df (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3cf5a36e87691c9e806e8e2adcbb966735c1012
commit e3cf5a36e87691c9e806e8e2adcbb966735c1012
Merge: 824fa31 25845b1
Author: Brad King 
AuthorDate: Wed May 11 15:08:58 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 15:08:58 2016 -0400

Merge topic 'pathscale-implicit-link-info' into next

25845b10 CMakeParseImplicitLinkInfo: Exclude pathcc ldfe lines (#16100)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25845b10d8ef2ded79fadf7eb924609ff0b142ae
commit 25845b10d8ef2ded79fadf7eb924609ff0b142ae
Author: Michał Górny 
AuthorDate: Wed May 11 19:52:31 2016 +0200
Commit: Brad King 
CommitDate: Wed May 11 15:06:59 2016 -0400

CMakeParseImplicitLinkInfo: Exclude pathcc ldfe lines (#16100)

PathScale uses a wrapper around the linker.  The "ldfe" invocation in
the output is followed by a normal "ld" invocation.  Exclude the former
so we can reach and parse the latter correctly.

diff --git a/Modules/CMakeParseImplicitLinkInfo.cmake 
b/Modules/CMakeParseImplicitLinkInfo.cmake
index 59092bd..ef9a2eb 100644
--- a/Modules/CMakeParseImplicitLinkInfo.cmake
+++ b/Modules/CMakeParseImplicitLinkInfo.cmake
@@ -31,7 +31,7 @@ function(CMAKE_PARSE_IMPLICIT_LINK_INFO text lib_var dir_var 
fwk_var log_var obj
   # Construct a regex to match linker lines.  It must match both the
   # whole line and just the command (argv[0]).
   set(linker_regex "^( *|.*[/\\])(${linker}|([^/\\]+-)?ld|collect2)[^/\\]*( 
|$)")
-  set(linker_exclude_regex "collect2 version |^[A-Za-z0-9_]+=")
+  set(linker_exclude_regex "collect2 version |^[A-Za-z0-9_]+=|/ldfe ")
   set(log "${log}  link line regex: [${linker_regex}]\n")
   string(REGEX REPLACE "\r?\n" ";" output_lines "${text}")
   foreach(line IN LISTS output_lines)

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1334-g824fa31

[Clinton Stimpson]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  824fa316be79bc424901f35176df3eaa087bc4df (commit)
   via  97775975d544b60aeb3810a07387fd11d229dfaa (commit)
  from  3f9a01c14cd232c8d1a3ecf552b42df131bbdd6e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=824fa316be79bc424901f35176df3eaa087bc4df
commit 824fa316be79bc424901f35176df3eaa087bc4df
Merge: 3f9a01c 9777597
Author: Clinton Stimpson 
AuthorDate: Wed May 11 14:52:32 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 14:52:32 2016 -0400

Merge topic 'cmake-gui-locale' into next

97775975 cmake-gui: set LC_NUMERIC = "C" at startup.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97775975d544b60aeb3810a07387fd11d229dfaa
commit 97775975d544b60aeb3810a07387fd11d229dfaa
Author: Clinton Stimpson 
AuthorDate: Wed May 11 12:51:32 2016 -0600
Commit: Clinton Stimpson 
CommitDate: Wed May 11 12:51:32 2016 -0600

cmake-gui: set LC_NUMERIC = "C" at startup.

diff --git a/Source/QtDialog/CMakeSetup.cxx b/Source/QtDialog/CMakeSetup.cxx
index b78a5df..1e1f040 100644
--- a/Source/QtDialog/CMakeSetup.cxx
+++ b/Source/QtDialog/CMakeSetup.cxx
@@ -94,6 +94,8 @@ int main(int argc, char** argv)
 
   QApplication app(argc, argv);
 
+  setlocale(LC_NUMERIC, "C");
+
 #if defined(CMAKE_ENCODING_UTF8)
   QTextCodec* utf8_codec = QTextCodec::codecForName("UTF-8");
   QTextCodec::setCodecForLocale(utf8_codec);

---

Summary of changes:
 Source/QtDialog/CMakeSetup.cxx |2 ++
 1 file changed, 2 insertions(+)


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

[CMake] [PATCH] FindBoost does not detect absence of header file

[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] in source makefile / helper script that enables building out of source?

[Paul Smith]

On Wed, 2016-05-11 at 09:06 -0500, Steve Lorimer wrote:
> I am aware of being able to do in-source builds, but would like to
> continue to reap the benefits of out-of-source builds whilst being
> able to build from in-source

Make a shell function or shell script to run your build, that does the
cd to the build directory and starts the build.
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1332-g3f9a01c

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  3f9a01c14cd232c8d1a3ecf552b42df131bbdd6e (commit)
   via  18df6a9a78fc0b450bd37d4394c7422cd56ec12b (commit)
  from  6de0012188c436d5a6fb84a7fd483f818de5ec1b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f9a01c14cd232c8d1a3ecf552b42df131bbdd6e
commit 3f9a01c14cd232c8d1a3ecf552b42df131bbdd6e
Merge: 6de0012 18df6a9
Author: Brad King 
AuthorDate: Wed May 11 11:06:40 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 11:06:40 2016 -0400

Merge topic 'clang-format-prep' into next

18df6a9a Tests: Protect unicode literals from clang-format Cpp03 formatting


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18df6a9a78fc0b450bd37d4394c7422cd56ec12b
commit 18df6a9a78fc0b450bd37d4394c7422cd56ec12b
Author: Brad King 
AuthorDate: Wed May 11 10:36:51 2016 -0400
Commit: Brad King 
CommitDate: Wed May 11 10:37:45 2016 -0400

Tests: Protect unicode literals from clang-format Cpp03 formatting

Since CMake is written in C++98 any clang-format configuration must
set `Standard` to `Cpp03` so that `A` is not rewritten as
`A`.  However, this will cause `U"foo"` to be rewritten as
`U "foo"`.  Add markup to turn clang-format off in the one place
that the latter case occurs so that we do not need a separate
`.clang-format` config file for it.

Inspired-by: Daniel Pfeifer 

diff --git a/Tests/CompileFeatures/cxx_unicode_literals.cpp 
b/Tests/CompileFeatures/cxx_unicode_literals.cpp
index a7b7df0..7794c11 100644
--- a/Tests/CompileFeatures/cxx_unicode_literals.cpp
+++ b/Tests/CompileFeatures/cxx_unicode_literals.cpp
@@ -1,3 +1,5 @@
 
+/* clang-format off */
 const char16_t lit_16[] = u"\u00DA";
 const char32_t lit_32[] = U"\u00DA";
+/* clang-format on */

---

Summary of changes:
 Tests/CompileFeatures/cxx_unicode_literals.cpp |2 ++
 1 file changed, 2 insertions(+)


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

[cmake-developers] [PATCH] FindBoost does not detect absence of header file

[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")
+  

[CMake] Visual Studio 2008 / VS Compiler for Python

[Michael Sarahan]

In compiling TBB, a conda-forge contributor ran across issues with CMake
not finding the VS compiler for VS 2008 Win64.

https://github.com/conda-forge/staged-recipes/pull/533

The exact error is at
https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L216

Appveyor is an interesting platform, in that they install VS 2008 Express,
then the VS compiler for Python (which adds the 64-bit compilation support).

How does CMake find compilers?  Does it need extra instruction of some sort
here?

This is occurring in the context of a conda build, so we have already run
the appropriate vcvars*.bat script by the time CMake runs  (
https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L185)
- but I'm not sure that really influences CMake's ability to find the
compiler.

Any guidance much appreciated.

Best,
Michael
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] in source makefile / helper script that enables building out of source?

[Steve Lorimer]

On 11 May 2016 at 09:01, Konstantin Tokarev  wrote:

>
> FYI, CMake supports in-source builds (however, particular projects may not)
>

Thanks for your response!

I am aware of being able to do in-source builds, but would like to continue
to reap the benefits of out-of-source builds whilst being able to build
from in-source
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] in source makefile / helper script that enables building out of source?

[Konstantin Tokarev]

11.05.2016, 16:58, "Steve Lorimer" :
> I've recently changed over from using boost-build 
> (http://www.boost.org/build/) to cmake.
>
> Boost build builds in-source.
>
> I've become quite used to building and searching etc from the source root
>
>> ~/src $ b2 module
>> ~/src $ git grep foo
>
> This work flow has been broken because I'm not using out of source builds
>
>> ~/src/build $ make module
>> ~/src/build $ git grep... dang it! 
>> ~/src/build $ cd ..
>> ~/src $ git grep foo
>> ~/src $ make modu... dang it! 
>> ~/src $ cd build
>> ~/src/build $ make module
> I can't be the only one who wants to have the benefit of out of source builds 
> and be able to build from in-source.
>
> I imagine it would be relatively simple to create a makefile which navigates 
> to a known build directory (eg: build or debug or...), executes make there, 
> and then changes directory back to where it was called from.
>
> Before I do just this, I thought it better to try leverage the open source 
> community - hence asking the question.
>
> Does anyone have a script or makefile which does just this?

FYI, CMake supports in-source builds (however, particular projects may not)


>
> TIA
> Steve
> ,--
>
> 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


-- 
Regards,
Konstantin
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1330-g6de0012

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  6de0012188c436d5a6fb84a7fd483f818de5ec1b (commit)
   via  eafe541ff6be9e73901f768c8ccff213a57036bd (commit)
   via  eb4f5104123a531bd49cb5834f3c66bb9e6aeeb6 (commit)
  from  230dfa6e6a29db28405c73085194540a1b66b2b3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6de0012188c436d5a6fb84a7fd483f818de5ec1b
commit 6de0012188c436d5a6fb84a7fd483f818de5ec1b
Merge: 230dfa6 eafe541
Author: Brad King 
AuthorDate: Wed May 11 10:08:02 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Wed May 11 10:08:02 2016 -0400

Merge topic 'ctest-suppress-Note' into next

eafe541f CTest: Do not treat "Note: ..." lines as errors (#14394)
eb4f5104 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eafe541ff6be9e73901f768c8ccff213a57036bd
commit eafe541ff6be9e73901f768c8ccff213a57036bd
Author: Brad King 
AuthorDate: Wed May 11 09:55:58 2016 -0400
Commit: Brad King 
CommitDate: Wed May 11 09:56:51 2016 -0400

CTest: Do not treat "Note: ..." lines as errors (#14394)

Otherwise CTest interprets the Qt5 moc tool output

Note: No relevant classes found. No output generated.

as a compiler error.

diff --git a/Source/CTest/cmCTestBuildHandler.cxx 
b/Source/CTest/cmCTestBuildHandler.cxx
index 9647968..ed0cad7 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -102,6 +102,7 @@ static const char* cmCTestErrorExceptions[] = {
   ": warning",
   ": \\(Warning\\)",
   ": note",
+  "Note:",
   "makefile:",
   "Makefile:",
   ":[ \\t]+Where:",

---

Summary of changes:
 Source/CMakeVersion.cmake|2 +-
 Source/CTest/cmCTestBuildHandler.cxx |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)


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

[CMake] in source makefile / helper script that enables building out of source?

[Steve Lorimer]

I've recently changed over from using boost-build (
http://www.boost.org/build/) to cmake.

Boost build builds in-source.

I've become quite used to building and searching etc from the source root

~/src $ b2 module
~/src $ git grep foo


This work flow has been broken because I'm not using out of source builds

~/src/build $ make module
~/src/build $ git grep... dang it! 
~/src/build $ cd ..
~/src $ git grep foo
~/src $ make modu... dang it! 
~/src $ cd build
~/src/build $ make module

I can't be the only one who wants to have the benefit of out of source
builds and be able to build from in-source.

I imagine it would be relatively simple to create a makefile which
navigates to a known build directory (eg: build or debug or...), executes
make there, and then changes directory back to where it was called from.

Before I do just this, I thought it better to try leverage the open source
community - hence asking the question.

Does anyone have a script or makefile which does just this?

TIA
Steve
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[iosif neitzke]

> When A links in B as PRIVATE, it is saying that A uses B in its
> implementation, but B is not used in any part of A's public API.

> When A links in B as INTERFACE, it is saying that A does not use B in its
> implementation, but B is used in A's public API.

> When A links in B as PUBLIC, it is essentially a combination of PRIVATE and
> INTERFACE. It says that A uses B in its implementation and B is also used in
> A's public API.

All totally correct, and that is how visibility for target_link and
target_include commands idiomatically should be used, but I don't
believe anything in CMake ensures the code architecture adheres to
this scheme.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[Craig Scott]

Hopefully the explanation that follows helps clarify what PRIVATE, PUBLIC
and INTERFACE mean and do. From my understanding of things, I think there
may have been some subtle inaccuracies in some of the discussions so far,
so hopefully the following is helpful and if I've got something wrong, then
by all means please point out the inaccuracies.


   - When A links in B as *PRIVATE*, it is saying that A uses B in its
   implementation, but B is not used in any part of A's public API. Any code
   that makes calls into A would not need to refer directly to anything from
   B. An example of this could be a networking library A which can be built to
   use one of a number of different SSL libraries internally (which B
   represents). A presents a unified interface for client code which does not
   reference any of the internal SSL data structures or functions. Client code
   would have no idea what SSL implementation (B) is being used by A, nor does
   that client code need to care.
   - When A links in B as *INTERFACE*, it is saying that A does not use B
   in its implementation, but B is used in A's public API. Code that calls
   into A may need to refer to things from B in order to make such calls. One
   example of this is an interface library which simply forwards calls along
   to another library but doesn't actually reference the objects on the way
   through other than by a pointer or reference. Another example is where A is
   defined in CMake as an interface library, meaning it has no actual
   implementation itself, it is effectively just a collection of other
   libraries (I'm probably over-simplifying here, but you get the picture).
   - When A links in B as *PUBLIC*, it is essentially a combination of
   PRIVATE and INTERFACE. It says that A uses B in its implementation and B is
   also used in A's public API.


Consider first what this means for include search paths. If something links
against A, it will also need any include search paths from B if B is in A's
public API. Thus, if A links in B either as PUBLIC or INTERFACE, then any
header search paths defined for target B will also apply to anything that
links to A. Any PRIVATE header search path for B will NOT be carried
through to anything that links only to A. The target_include_directories()
command handles this. The situation with compile flags is analogously
handled with target_compile_definitions() and target_compile_options().

Now consider the situation for the actual libraries involved. If A is a
shared library, then A will have encoded into it a dependency on B. This
information can be inspected with tools like ldd on Linux, otool on Mac and
something like Dependency Walker (a.k.a. depends.exe) on Windows. If other
code links directly to A, then it also will have encoded into it a
dependency on A. It will not, however, have a dependency on B unless A
links in B as PUBLIC or INTERFACE. So far, so good. If, however, A is a
static library, the situation changes. Static libraries do not carry
information about other libraries they depend on. For this reason, when A
links in B as PRIVATE and another target C links in A, CMake will still add
B to the list of libraries to be linked for C because parts of B are needed
by A, but A itself doesn't have that dependency encoded into it. So even
though B is an internal implementation detail of A, C still needs B added
to the linker command, which CMake conveniently handles for you.

If you were paying careful attention, you would have noticed that when A
links in B as PRIVATE, the include directories of B never propagate to
something linking to A, but if A is a static library, then the *linking* of
B behaves as though the relationship was PUBLIC. This
PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the
*linking*, not to the other dependencies (compiler options/flags and
include search paths). The upshot of all this is that if you select
PRIVATE, PUBLIC or INTERFACE based on the explanations in the dot points
above, then CMake will ensure dependencies propagate through to where they
are required, regardless of whether libraries are static or shared. This
does, of course, rely on you the developer not missing any dependencies or
specifying the wrong PRIVATE/PUBLIC/INTERFACE relationship.

As a final note, if you call target_link_libraries() and do not specify any
of PRIVATE, PUBLIC or INTERFACE, you may be tempted to believe that it will
be treated as PUBLIC. The situation is actually more complicated than that
though. It may be treated as PUBLIC or PRIVATE, depending on what other
target_link_library() calls and/or target property manipulations have been
performed. The documentation for target_link_libraries() talks a bit about
this, but you have to go digging into the documentation for the target
properties it mentions to get an understanding of what circumstances lead
to PRIVATE or PUBLIC behaviour.

Hope that helps clarify some things. Sorry if this has gone off on a
tangent 

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[iosif neitzke]

>> I *think* that these public/private rules behave a bit differently
>> for static libraries than they do for shared ones.

They do.  Assuming main calls a() and b() defined in A_lib and B_lib
respectively, for:
add_library(A_lib STATIC a.c)
add_library(B_lib STATIC b.c)
target_link_libraries(A_lib PRIVATE B_lib)
add_executable(main main.c)
target_link_libraries(main A_lib)

The PRIVATE in "target_link_libraries(A_lib PRIVATE B_lib)" is
useless.  It is the same as writing "target_link_libraries(A_lib
PUBLIC B_lib)", only more confusing to the reader. Static libraries
always link to their dependencies publically.

https://cmake.org/cmake/help/v3.5/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents

However, if you change A_lib to be a shared library with
"add_library(A_lib SHARED a.c)" and left the rest of the code the
same, you would now get link errors for main not able to find b(),
because A_lib now does not pass on its dependency on B, it hides it
from main.   Change the last line to "target_link_libraries(main A_lib
B_lib)" and main builds again.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Xcode generator results in a project file without optimization

[Siyuan Ren]

OK, I got it. It worked all the time, but I looked at the wrong scheme/target.

On Wed, May 11, 2016 at 3:05 PM, Gregor Jasny  wrote:
> On 11/05/16 08:40, Siyuan Ren wrote:
>> Attached are a minimal demonstration and a screenshot of what Xcode
>> shows me when it opens the project.
>
> This also works for me. In your Xcode project file also everything looks
> normal (see GCC_OPTIMIZATION_LEVEL).
>
> Could you please switch your Xcode Build Settings View from "Combined"
> to "Levels"? I suspect you have an xcconfig file loaded via an
> environment variable which shadows the build settings.
>
> 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

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

[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

[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

Re: [CMake] AUTOMOC with files on different folders

[Attila Krasznahorkay]

Hi Tiago,

This is one of those cases when you have to declare the header files to 
add_library(...) as well. In that case AUTOMOC should work fine. At least it 
does for us, in a very similar setup.

http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/graphics/VP1/VP1Gui/CMakeLists.txt

Cheers,
Attila

> On 11 May 2016, at 07:14, Tiago Macarios  wrote:
> 
> Hi,
> 
> I am having trouble using AUTOMOC with a project where header files and 
> source files are in different sub-directories. I wrote a detailed stack 
> overflow question here:
> http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders
> and would really appreciate if someone could give me a couple of ideas to try 
> out.
> 
> Thanks,
> Tiago
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning

[Attila Krasznahorkay]

Hi,

I'm a bit surprised by this. I had to explicitly tell CMake not to treat 
includes coming from imported targets as system includes. Using this variable:

https://cmake.org/cmake/help/v3.0/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html

So I think this is in general a MacOS specific issue. I remember reading about 
such issues a while ago. That CMake would not recognise that MacOS X's clang 
would accept the -isystem argument out of the box.

Cheers,
  Attila

> On 10 May 2016, at 18:16, tetractius  wrote:
> 
> Hi list,
> 
> I have an issue caused by a warning in the qt5 brew version in osx when using 
> Xcode generator
> 
> I can safely find the qt framework in the brew cellar:
> 
> set(CMAKE_PREFIX_PATH /usr/local/opt/qt5)
> find_package(Qt5Widgets REQUIRED)
> 
> and with this I can easily add this framework to my project by using
> 
> target_link_libraries(myApp Qt5::Widgets)
> 
> and this, as per documentation will cause to add all the -I directories> when compiling the .o files for this target.
> 
> The problem is that QT has some warning in their headers at the version 5.6 
> and 5.5.2_1 (that is all the qt5 the versions available in brew)
> and the -I it is not a system include parameter.
> 
> 
> So assuming that I cannot avoid to use the brew version and I cannot fix the 
> problems in the qt5 headers,
> 
> How can I tell to cmake that these framework include directories are system 
> include directories and thus they need to be included with -isystem in the 
> xcode project?
> 
> I tryed to manually pass the flag to the compiler but the 
> target_link_libraries function, when used with the framework, it will always 
> put their include directories in front of mine without the isystem flag.
> 
> 
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016100]: Implicit link information parsing reads the wrong line from 'pathcc -v' output

[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