[Cmake-commits] CMake branch, next, updated. v3.4.1-1688-g68f9dcb

[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  68f9dcba60f873d3091a1201a88dfdc2e26a1bb1 (commit)
   via  1549927d7dc29476ada7b0c0867e9630ebe6ea00 (commit)
  from  2e600b5a0fc16027df9b2138164bc5268c6fc9b6 (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=68f9dcba60f873d3091a1201a88dfdc2e26a1bb1
commit 68f9dcba60f873d3091a1201a88dfdc2e26a1bb1
Merge: 2e600b5 1549927
Author: Brad King 
AuthorDate: Thu Dec 10 14:23:30 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 14:23:30 2015 -0500

Merge topic 'FindOpenMP-clang' into next

1549927d FindOpenMP: Add Clang support


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1549927d7dc29476ada7b0c0867e9630ebe6ea00
commit 1549927d7dc29476ada7b0c0867e9630ebe6ea00
Author: Chris Pavlina 
AuthorDate: Thu Dec 10 10:40:27 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 14:19:35 2015 -0500

FindOpenMP: Add Clang support

diff --git a/Help/release/dev/FindOpenMP-clang.rst 
b/Help/release/dev/FindOpenMP-clang.rst
new file mode 100644
index 000..44c805c
--- /dev/null
+++ b/Help/release/dev/FindOpenMP-clang.rst
@@ -0,0 +1,4 @@
+FindOpenMP-clang
+
+
+* The :module:`FindOpenMP` module learned to support Clang.
diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake
index a102c66..ee4bdd6 100644
--- a/Modules/FindOpenMP.cmake
+++ b/Modules/FindOpenMP.cmake
@@ -50,6 +50,8 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
 " "
 #GNU
 "-fopenmp"
+#Clang
+"-fopenmp=libomp"
 #Microsoft Visual Studio
 "/openmp"
 #Intel windows
@@ -67,6 +69,7 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
   )
 
   set(OMP_FLAG_GNU "-fopenmp")
+  set(OMP_FLAG_Clang "-fopenmp=libomp")
   set(OMP_FLAG_HP "+Oopenmp")
   if(WIN32)
 set(OMP_FLAG_Intel "-Qopenmp")

---

Summary of changes:
 Help/release/dev/FindOpenMP-clang.rst |4 
 Modules/FindOpenMP.cmake  |3 +++
 2 files changed, 7 insertions(+)
 create mode 100644 Help/release/dev/FindOpenMP-clang.rst


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1692-g65b3b57

[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  65b3b57e0b5d3c9e8f0b8fff5fa336c00a3e1644 (commit)
   via  4c60e07d857277f1edc45358b35c6f50439324b4 (commit)
   via  a42bf6c5ddc70e0b15bbf60f11678aae71ff1f56 (commit)
   via  93936d78d221ea49f918f95e33b97796b2a3190f (commit)
  from  68f9dcba60f873d3091a1201a88dfdc2e26a1bb1 (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=65b3b57e0b5d3c9e8f0b8fff5fa336c00a3e1644
commit 65b3b57e0b5d3c9e8f0b8fff5fa336c00a3e1644
Merge: 68f9dcb 4c60e07
Author: Brad King 
AuthorDate: Thu Dec 10 14:35:20 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 14:35:20 2015 -0500

Merge topic 'release-wix-config' into next

4c60e07d CMake: Fix WiX-generated .msi package file name convention
a42bf6c5 Utilities/Release: Add support for copying .msi files
93936d78 Utilities/Release: Avoid repeat copy of files with same suffix


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c60e07d857277f1edc45358b35c6f50439324b4
commit 4c60e07d857277f1edc45358b35c6f50439324b4
Author: Brad King 
AuthorDate: Thu Dec 10 14:33:40 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 14:33:40 2015 -0500

CMake: Fix WiX-generated .msi package file name convention

Update our configuration of the CPack WIX generator for CMake itself to
produce file names consistent with other CPack generators.

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index ae00653..4ebf306 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -194,9 +194,9 @@ if("${CPACK_GENERATOR}" STREQUAL "WIX")
   # Reset CPACK_PACKAGE_VERSION to deal with WiX restriction.
   # But the file names still use the full CMake_VERSION value:
   set(CPACK_PACKAGE_FILE_NAME
-"${CPACK_PACKAGE_NAME}-@CMake_VERSION@-${CPACK_SYSTEM_NAME}")
+"cmake-@CMake_VERSION@-${CPACK_SYSTEM_NAME}")
   set(CPACK_SOURCE_PACKAGE_FILE_NAME
-"${CPACK_PACKAGE_NAME}-@CMake_VERSION@-Source")
+"cmake-@CMake_VERSION@")
 
   if(NOT CPACK_WIX_SIZEOF_VOID_P)
 set(CPACK_WIX_SIZEOF_VOID_P "@CMAKE_SIZEOF_VOID_P@")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a42bf6c5ddc70e0b15bbf60f11678aae71ff1f56
commit a42bf6c5ddc70e0b15bbf60f11678aae71ff1f56
Author: Brad King 
AuthorDate: Thu Dec 10 14:30:55 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 14:30:55 2015 -0500

Utilities/Release: Add support for copying .msi files

diff --git a/Utilities/Release/release_cmake.cmake 
b/Utilities/Release/release_cmake.cmake
index f41ec9c..0a3d324 100644
--- a/Utilities/Release/release_cmake.cmake
+++ b/Utilities/Release/release_cmake.cmake
@@ -112,6 +112,9 @@ foreach(gen ${generators})
   if("${gen}" STREQUAL "TZ")
 set(SUFFIXES ${SUFFIXES} "*.tar.Z")
   endif()
+  if("${gen}" STREQUAL "WIX")
+set(SUFFIXES ${SUFFIXES} "*.msi")
+  endif()
   if("${gen}" STREQUAL "ZIP")
 set(SUFFIXES ${SUFFIXES} "*.zip")
   endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93936d78d221ea49f918f95e33b97796b2a3190f
commit 93936d78d221ea49f918f95e33b97796b2a3190f
Author: Brad King 
AuthorDate: Thu Dec 10 14:28:57 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 14:29:37 2015 -0500

Utilities/Release: Avoid repeat copy of files with same suffix

diff --git a/Utilities/Release/release_cmake.cmake 
b/Utilities/Release/release_cmake.cmake
index c50602d..f41ec9c 100644
--- a/Utilities/Release/release_cmake.cmake
+++ b/Utilities/Release/release_cmake.cmake
@@ -120,6 +120,10 @@ foreach(gen ${generators})
   endif()
 endforeach()
 
+if(SUFFIXES)
+  list(REMOVE_DUPLICATES SUFFIXES)
+endif()
+
 if(LOCAL_DIR)
   file(MAKE_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/${LOCAL_DIR}")
 else()

---

Summary of changes:
 CMakeCPackOptions.cmake.in|4 ++--
 Utilities/Release/release_cmake.cmake |7 +++
 2 files changed, 9 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1684-g64cfea7

[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  64cfea7261834d8075ab5d844e0779bae4c3724c (commit)
   via  4f8ab578a2e9e1221fb56463d02864ed429b8613 (commit)
  from  987c2cf1d8ae76df4bf5bfc93745d898f981bff7 (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=64cfea7261834d8075ab5d844e0779bae4c3724c
commit 64cfea7261834d8075ab5d844e0779bae4c3724c
Merge: 987c2cf 4f8ab57
Author: Brad King 
AuthorDate: Thu Dec 10 13:54:47 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 13:54:47 2015 -0500

Merge topic 'simplify-CTest.UpdateGIT-test' into next

4f8ab578 fixup! Tests: Simplify CTest.UpdateGIT repo path construction


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f8ab578a2e9e1221fb56463d02864ed429b8613
commit 4f8ab578a2e9e1221fb56463d02864ed429b8613
Author: Brad King 
AuthorDate: Thu Dec 10 13:54:37 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 13:54:37 2015 -0500

fixup! Tests: Simplify CTest.UpdateGIT repo path construction

diff --git a/Tests/CTestUpdateGIT.cmake.in b/Tests/CTestUpdateGIT.cmake.in
index 4731f9e..46230cc 100644
--- a/Tests/CTestUpdateGIT.cmake.in
+++ b/Tests/CTestUpdateGIT.cmake.in
@@ -70,17 +70,17 @@ run_child(WORKING_DIRECTORY ${TOP}/module
 #-
 # Import initial content into the repository.
 message("Importing content...")
-create_content(import)
-file(WRITE ${TOP}/import/HEAD "HEAD\n")
-file(WRITE ${TOP}/import/master "master\n")
 
 # Import the content into the repository.
-run_child(WORKING_DIRECTORY ${TOP}/import
-  COMMAND ${GIT} init
+run_child(WORKING_DIRECTORY ${TOP}
+  COMMAND ${GIT} clone repo.git import
   )
 file(REMOVE_RECURSE ${TOP}/import/.git/hooks)
 file(APPEND ${TOP}/import/.git/config "
 ${AUTHOR_CONFIG}")
+create_content(import)
+file(WRITE ${TOP}/import/HEAD "HEAD\n")
+file(WRITE ${TOP}/import/master "master\n")
 run_child(WORKING_DIRECTORY ${TOP}/import
   COMMAND ${GIT} add .
   )
@@ -94,7 +94,7 @@ run_child(WORKING_DIRECTORY ${TOP}/import
   COMMAND ${GIT} commit -m "Initial content"
   )
 run_child(WORKING_DIRECTORY ${TOP}/import
-  COMMAND ${GIT} push ../repo.git master:refs/heads/master
+  COMMAND ${GIT} push origin master:refs/heads/master
   )
 
 #-

---

Summary of changes:
 Tests/CTestUpdateGIT.cmake.in |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)


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

Re: [cmake-developers] [PATCH] Add Clang support to FindOpenMP

[Brad King]

On 12/10/2015 10:49 AM, Chris Pavlina wrote:
> Attached is a patch to add the correct option for building OpenMP
> code using Clang.

Thanks, applied:

 FindOpenMP: Add Clang support
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1549927d

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1

[David Cole via CMake]

I've got a Debug build of current 'master' on Windows, and the problem is
also evident with my build:


C:\dev\dcole\tmp\variable_watch_problem\b1> "C:\dev\repos\My Tests\cmake
Win32-ninja-cl12-Debug\bin\
cmake.exe" -G Ninja ..
-- The CXX compiler identification is MSVC 18.0.31101.0
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:161 (include):
  include could not find load file:


÷░♣A/Fin
dPackageHandleStandardArgs.cmake
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:162
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
:
  Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS".
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


-- Configuring incomplete, errors occurred!
See also
"C:/dev/dcole/tmp/variable_watch_problem/b1/CMakeFiles/CMakeOutput.log".


On Thu, Dec 10, 2015 at 7:26 AM, Yves Frederix <
yves.frederix+cm...@gmail.com> wrote:

> After commenting out the call there is no error output:
>
>   -- The CXX compiler identification is MSVC 17.0.61030.0
>   -- Check for working CXX compiler using: Visual Studio 11 2012 Win64
>   -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 --
> works
>   -- Detecting CXX compiler ABI info
>   -- Detecting CXX compiler ABI info - done
>   -- Detecting CXX compile features
>   -- Detecting CXX compile features - done
>   -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.10")
>   -- Configuring done
>   -- Generating done
>
>
> Yves
>
> On Thu, Dec 10, 2015 at 12:58 PM, David Cole  wrote:
>
>> Out of curiosity, what output do you get (with 3.4.1) when you comment
>> out your call to variable_watch? Do you still get error output, but without
>> strange symbols in it? Or is there no error output in that case?
>>
>>
>> On Thursday, December 10, 2015, Yves Frederix <
>> yves.frederix+cm...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am experiencing problems during the CMake configure step when using
>>> the function variable_watch. Consider the following minimal CMakeLists
>>> file:
>>>
>>>   cmake_minimum_required(VERSION 3.4)
>>>   project(test CXX)
>>>
>>>   function(myhook _variable _access _value _current_list_file _stack)
>>> if("${_value}" STREQUAL "")
>>>   # Do nothing
>>> endif()
>>>   endfunction()
>>>
>>>   variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
>>>   find_package(PythonInterp REQUIRED)
>>>
>>>
>>> When configuring on Windows using CMake 3.4.1 with the Visual Studio
>>> generator (I tried both VS2012 and VS2015), the process fails with an
>>> error message (notice the strange symbols at the beginning of the line
>>> mentioning FindPackageMessage.cmake):
>>>
>>>   -- Detecting CXX compile features - done
>>> CMake Error at
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
>>> (include):
>>>   include could not find load file:
>>>
>>> L☺
>>> /Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
>>> Call Stack (most recent call first):
>>>   C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
>>> (include)
>>>   CMakeLists.txt:12 (find_package)
>>>
>>>
>>>   CMake Error at
>>>
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
>>> (FIND_PACKAGE_MESSAGE):
>>>   Unknown CMake command "FIND_PACKAGE_MESSAGE".
>>>   Call Stack (most recent call first):
>>>
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
>>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>> CMakeLists.txt:12 (find_package)
>>>
>>>
>>> I did some more testing, and the configuration step is successful when:
>>> - using CMake 2.8.12 or 3.4.0
>>> - using 3.4.1 (or older versions) on osx (I did not try linux)
>>> - removing the 'CXX' in the project call or removing the project call
>>> entirely
>>> - removing the check for _value inside the function
>>>
>>> It seems that for some reason adding the watch (which actually only
>>> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR
>>> variable is messed up somehow. Could I have run into some corner case
>>> behavior here?
>>>
>>> Maybe it is also useful to mention how I ended up in this situation.
>>> My requirement was to run some custom code as the very last step of
>>> the configure process. The solution I found was based on using
>>> variable_watch (see
>>>
>>> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843
>>> ),
>>> but apparently this is not a very robust solution. Are there possibly
>>> better ways 

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> Hi,
> 
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")

Assuming I wouldn't know about the subtle characteristics of normal vs. 
cache variables, I think I would expect that var has the value of the option 
afterwards.

I.e. on the first run it would be OFF (since that's the default value of the 
option), and all later runs it would have the value which is in the cache.

Alex

-- 

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 target_link_libraries items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1

[J Decker]

On Thu, Dec 10, 2015 at 12:15 AM, Petr Kmoch  wrote:
> Hi,
>
> Side note: you probably shouldn't be using the -l prefix with arguments to
> target_link_libraries(). The arguments are normally supposed to be either
> CMake target names, or full paths to the libraries you want to link. No need
> to prefix them with linker command-line options, CMake does that for you
> accordingly.

CMake/build system will typically search the library path, so you
don't need full paths... typically just the name of the library...
should be more like ..

target_link_libraries(Debug ${VTK_LIBRARIES} sri-spatialfft
sri-spatial sri-memory)


>
> Petr
>
> On Wed, Dec 9, 2015 at 6:22 PM, Normand Robert
>  wrote:
>>
>> robert@kalymnos:~/Code/Debug/normandBuild$ cmake --version
>> cmake version 3.4.1
>>
>> Reading docs trying to understand why my build works when I write
>>
>> target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft
>> -lsri-spatial -lsri-memory)
>>
>> but not when everything is protected in quotes:
>>
>> target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft
>> -lsri-spatial -lsri-memory")
>>
>> which causes an extra library which does not exist to be passed to the
>> linker. Is this expected behaviour?
>>
>> --
>> Normand Robert PhD
>> Sunnybrook Health Sciences Centre
>> Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5
>>
-- 

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] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Hi,

I identify the root of the problem: if I specify version 3.4 in 
cmake_minimum_required, generated link command (stored in file link.txt) for an 
executable does not contains value specified in variable 
CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. So 
this is a regression introduced in 3.4.

Problem can be reproduced using this very simple CMakeLists.txt:
cmake_minimum_required (VERSION 3.4)

project (TEST LANGUAGES CXX)

file (WRITE test.cpp "// empty\n")

add_executable (test_exe test.cpp)

This problem occurs on all platforms (tested on AIX and Linux).

Marc




On 09/12/15 15:41, "cmake-developers on behalf of CHEVRIER, Marc" 
 wrote:

>
>Oops !
>You are right, on a simple example, all is OK. So the problem seems on my side.
>I will investigate this curious behaviour…
>
>Sorry for the noise.
>
>Marc
>
>
>
>
>On 09/12/15 15:15, "Brad King"  wrote:
>
>>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
>>> You are right. I missed this capability.
>>> My first idea was to apply to exec the same approach as for shared lib but 
>>> I didn’t found appropriate variable: something like 
>>> CMAKE_EXE_CREATE__FLAGS
>>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
>>> usage of the *_INIT variables.
>>
>>Actually the old code has it in two places:
>>
>>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # 
>>> -shared
>>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS 
>>> "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib
>>
>>The CREATE_ value is used when linking a shared library itself.
>>The LINK_ value is used to link executables.  Both should already
>>be getting the flag with no changes.
>>
>>-Brad
>>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] organizing includes statements

[Owen Alanzo Hogarth]

oh cool
adding target_include_directories(lib1 PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/headers)

and then I can just use #include "lib1" where needed. No more of those very
static paths!

Thank you very much!

On Thu, Dec 10, 2015 at 4:08 PM, iosif neitzke <
iosif.neitzke+cm...@gmail.com> wrote:

> I would think
>
> add_library( lib1 SHARED lib1/lib1.c )
> target_include_directories( lib1 PUBLIC lib1/headers )
>
> is simpler.  Are the generator expressions needed for target export
> install commands, and is exporting targets at install preferred to
> add_subdirectory() ?
>
> On Thu, Dec 10, 2015 at 1:48 AM, Owen Alanzo Hogarth
>  wrote:
> > my main CMakeLists.txt file already has a few directives that move the
> libs
> > to an output folder so the binaries go to /bin while static and shared
> > libraries go to /lib
> >
> > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
> >
> >
> > it seems like this line in your reply above
> > install( TARGETS lib1 lib2 DESTINATION lib )
> >
> > moves the shared libraries to the lib folder and this line below moves
> the
> > header files to the newly created include directory.
> >
> > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION
> include )
> >
> > is that right?
> >
> > On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay
> >  wrote:
> >>
> >> Hi Owen,
> >>
> >> This seems like a textbook example of using
> target_include_directories(…)
> >> with generator expressions. Let’s take the example where:
> >>
> >> lib1/headers/lib1.h
> >> lib1/lib1.c
> >> lib2/headers/lib2.h
> >> lib2/lib2.c
> >>
> >> If you want to be able to include lib1.h and lib2.h with simply
> >>
> >> #include “lib1.h”
> >>
> >> and
> >>
> >> #include “lib2.h”
> >>
> >> in your user code, and in the library code itself, you’d do something
> >> like:
> >>
> >> add_library( lib1 SHARED lib1/lib1.c )
> >> target_include_directories( lib1 PUBLIC
> >>$
> >>$ )
> >>
> >> add_library( lib2 SHARED lib2/lib2.c )
> >> target_include_directories( lib2 PUBLIC
> >>$
> >>$ )
> >> target_link_libraries( lib2 lib1 )
> >>
> >> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION
> include
> >> )
> >> install( TARGETS lib1 lib2 DESTINATION lib )
> >>
> >> In this setup “lib1” should get a -I${CMAKE_SOURCE_DIR}/lib1/headers
> flag,
> >> and “lib2” should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and
> >> -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get
> installed
> >> into the same include directory, so an outside user will just have to be
> >> able to find that one directory. (Or if you export CMake’s targets, the
> >> lib1/2 imported targets will know that their header files are in that
> >> directory.)
> >>
> >> Cheers,
> >> Attila
> >>
> >> > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth <
> gurenc...@gmail.com>
> >> > wrote:
> >> >
> >> > hi
> >> >
> >> > I am building a shared library project that's composed of many smaller
> >> > shared library files.
> >> >
> >> > Here's the main shared library project and a list of all the sub
> >> > projects.
> >> >
> >> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h)
> >> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c)
> >> > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils)
> >> >
> >> > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES})
> >> > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS})
> >> >
> >> > i have each module setup like this.
> >> > module
> >> > module/headers/module.h
> >> > module/module.c
> >> >
> >> > then the module.c will look like this
> >> > #include "headers/module.h"
> >> >
> >> > the file main_lib.h depends on all those target libs, which makes my
> >> > main_lib.h file's include statement look like this
> >> >
> >> > #include "../../module/headers/module.h"
> >> > #include "../../module1/headers/module1.h"
> >> > #include "../../module2/headers/module2.h"
> >> >
> >> >
> >> > is there any way that I can clean up these includes?
> >> >
> >> > For example if I want to use io functions I can just do #include
> >> >  or #include 
> >> >
> >> > for math functions.
> >> >
> >> > I would like to make my include statements not relative to the files
> >> > actual location, the way it's currently hard coded.
> >> > --
> >> >
> >> > 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
> 

Re: [CMake] organizing includes statements

[Owen Alanzo Hogarth]

that's actually a good point. Currently as I am developing this i am doing
an out of source build and just testing it from there but eventually what I
want is a shared library that can be used by other programs.

currently though my other programs is just a simple main.c that includes
the main library which includes all the sub libraries.

One of the reasons why I chose to just set the paths as I did was that I
couldn't get the install command to work, not sure why exactly at that time
I was just getting started with cmake so most likely user error. It's been
working so far and the main concern right now is to get this c program
working then refine the cmake build as I go.

I just moved the bin directory to my desktop for testing, that seemed to
work but this is something to keep in mind.

On Thu, Dec 10, 2015 at 4:20 PM, Raymond Wan  wrote:

> Hi Owen,
>
> Sorry to jump into the discussion, but what you're talking is
> something I was thinking of just recently...
>
> I think the choice between this:
>
>
> On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
>  wrote:
> > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
>
>
> and this:
>
>
> > it seems like this line in your reply above
> > install( TARGETS lib1 lib2 DESTINATION lib )
> > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION
> include )
>
>
> comes down to whether you want to compile other programs with these
> libraries.  If you will not, then you can set the paths to
> CMAKE_BINARY_DIR, which is the path to the top of the build tree.  As
> far as I know, after you compile your program, you can/should delete
> the build tree (i.e., assuming an out-of-source build).
>
> So, most likely, you'd want to pick the second option if you need the
> header files and archives to build something else.  This is because
> when you run cmake, you can set the prefix to install files to (i.e.,
> using "make install").  In my case, I only need header files and
> archives to build something within a single build (i.e., various
> inter-related subdirectories, all under one CMakeLists.txt).  So, I do
> something similar to the first option.
>
> I did toy with the second option a bit but, in the end, realized that
> much of what I wrote won't be reused by another project of mine.  At
> least, that's my understanding of the two options above...
>
> Ray
>
-- 

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] organizing includes statements

[iosif neitzke]

I would think

add_library( lib1 SHARED lib1/lib1.c )
target_include_directories( lib1 PUBLIC lib1/headers )

is simpler.  Are the generator expressions needed for target export
install commands, and is exporting targets at install preferred to
add_subdirectory() ?

On Thu, Dec 10, 2015 at 1:48 AM, Owen Alanzo Hogarth
 wrote:
> my main CMakeLists.txt file already has a few directives that move the libs
> to an output folder so the binaries go to /bin while static and shared
> libraries go to /lib
>
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
>
>
> it seems like this line in your reply above
> install( TARGETS lib1 lib2 DESTINATION lib )
>
> moves the shared libraries to the lib folder and this line below moves the
> header files to the newly created include directory.
>
> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )
>
> is that right?
>
> On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay
>  wrote:
>>
>> Hi Owen,
>>
>> This seems like a textbook example of using target_include_directories(…)
>> with generator expressions. Let’s take the example where:
>>
>> lib1/headers/lib1.h
>> lib1/lib1.c
>> lib2/headers/lib2.h
>> lib2/lib2.c
>>
>> If you want to be able to include lib1.h and lib2.h with simply
>>
>> #include “lib1.h”
>>
>> and
>>
>> #include “lib2.h”
>>
>> in your user code, and in the library code itself, you’d do something
>> like:
>>
>> add_library( lib1 SHARED lib1/lib1.c )
>> target_include_directories( lib1 PUBLIC
>>$
>>$ )
>>
>> add_library( lib2 SHARED lib2/lib2.c )
>> target_include_directories( lib2 PUBLIC
>>$
>>$ )
>> target_link_libraries( lib2 lib1 )
>>
>> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include
>> )
>> install( TARGETS lib1 lib2 DESTINATION lib )
>>
>> In this setup “lib1” should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag,
>> and “lib2” should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and
>> -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed
>> into the same include directory, so an outside user will just have to be
>> able to find that one directory. (Or if you export CMake’s targets, the
>> lib1/2 imported targets will know that their header files are in that
>> directory.)
>>
>> Cheers,
>> Attila
>>
>> > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth 
>> > wrote:
>> >
>> > hi
>> >
>> > I am building a shared library project that's composed of many smaller
>> > shared library files.
>> >
>> > Here's the main shared library project and a list of all the sub
>> > projects.
>> >
>> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h)
>> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c)
>> > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils)
>> >
>> > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES})
>> > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS})
>> >
>> > i have each module setup like this.
>> > module
>> > module/headers/module.h
>> > module/module.c
>> >
>> > then the module.c will look like this
>> > #include "headers/module.h"
>> >
>> > the file main_lib.h depends on all those target libs, which makes my
>> > main_lib.h file's include statement look like this
>> >
>> > #include "../../module/headers/module.h"
>> > #include "../../module1/headers/module1.h"
>> > #include "../../module2/headers/module2.h"
>> >
>> >
>> > is there any way that I can clean up these includes?
>> >
>> > For example if I want to use io functions I can just do #include
>> >  or #include 
>> >
>> > for math functions.
>> >
>> > I would like to make my include statements not relative to the files
>> > actual location, the way it's currently hard coded.
>> > --
>> >
>> > 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: 

Re: [CMake] CMake target_link_libraries items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1

[Petr Kmoch]

Hi,

yes, that is indeed expected behaviour. target_link_libraries() takes a
CMake list of arguments - one library per argument. When you surround the
thing with quotes, it's a single argument (containing some spaces). So for
this call:

target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft
-lsri-spatial -lsri-memory")

CMake will instruct the linker to look for a library named " -sri-spatialfft -lsri-spatial -lsri-memory" (one file name
with spaces and semicolons in it). Since such a library does not exist,
that fails.

Without the quotes, each element of the list VTK_LIBRARIES will be a
separate argument to target_link_libraries, as will "-lsri-spatialfft",
"-lsri-spatial", and "-lsri-memory".

Side note: you probably shouldn't be using the -l prefix with arguments to
target_link_libraries(). The arguments are normally supposed to be either
CMake target names, or full paths to the libraries you want to link. No
need to prefix them with linker command-line options, CMake does that for
you accordingly.

Petr

On Wed, Dec 9, 2015 at 6:22 PM, Normand Robert <
normand.rob...@sri.utoronto.ca> wrote:

> robert@kalymnos:~/Code/Debug/normandBuild$ cmake --version
> cmake version 3.4.1
>
> Reading docs trying to understand why my build works when I write
>
> target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft
> -lsri-spatial -lsri-memory)
>
> but not when everything is protected in quotes:
>
> target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft
> -lsri-spatial -lsri-memory")
>
> which causes an extra library which does not exist to be passed to the
> linker. Is this expected behaviour?
>
> --
> Normand Robert PhD
> Sunnybrook Health Sciences Centre
> Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5
>
> --
>
> 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] organizing includes statements

[Raymond Wan]

Hi Owen,

Sorry to jump into the discussion, but what you're talking is
something I was thinking of just recently...

I think the choice between this:


On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
 wrote:
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)


and this:


> it seems like this line in your reply above
> install( TARGETS lib1 lib2 DESTINATION lib )
> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )


comes down to whether you want to compile other programs with these
libraries.  If you will not, then you can set the paths to
CMAKE_BINARY_DIR, which is the path to the top of the build tree.  As
far as I know, after you compile your program, you can/should delete
the build tree (i.e., assuming an out-of-source build).

So, most likely, you'd want to pick the second option if you need the
header files and archives to build something else.  This is because
when you run cmake, you can set the prefix to install files to (i.e.,
using "make install").  In my case, I only need header files and
archives to build something within a single build (i.e., various
inter-related subdirectories, all under one CMakeLists.txt).  So, I do
something similar to the first option.

I did toy with the second option a bit but, in the end, realized that
much of what I wrote won't be reused by another project of mine.  At
least, that's my understanding of the two options above...

Ray
-- 

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.4.1-1695-gcaa83f4

[Gregor Jasny via Cmake-commits]

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  caa83f4e41630cd00e8e32f2330d2c1be045b95f (commit)
   via  565d080a9a1e133bda868e905226181b60e90356 (commit)
   via  34f5ef564aa94f2f66f35c708dbfca260b419e4b (commit)
  from  65b3b57e0b5d3c9e8f0b8fff5fa336c00a3e1644 (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=caa83f4e41630cd00e8e32f2330d2c1be045b95f
commit caa83f4e41630cd00e8e32f2330d2c1be045b95f
Merge: 65b3b57 565d080
Author: Gregor Jasny 
AuthorDate: Thu Dec 10 16:42:16 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 16:42:16 2015 -0500

Merge topic 'ios-universal' into next

565d080a Xcode: Add support for combined install on iOS
34f5ef56 iOS: Fix App Bundle layout


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=565d080a9a1e133bda868e905226181b60e90356
commit 565d080a9a1e133bda868e905226181b60e90356
Author: Ruslan Baratov 
AuthorDate: Thu Oct 8 03:09:34 2015 +0300
Commit: Gregor Jasny 
CommitDate: Thu Dec 10 22:36:12 2015 +0100

Xcode: Add support for combined install on iOS

This patch solves the problem of installing both: Device and Simulator
libraries on iOS. Before only one of them was installed.

If the IOS_INSTALL_COMBINED property is set on a target, a
special install hook will be activated which builds the corresponding
target and combines both at the install location.

The original patch was contributed by Ruslan Baratov, and polished by
Gregor Jasny.

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 931363c..a41d484 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -191,6 +191,7 @@ Properties on Targets
/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION_CONFIG
/prop_tgt/INTERPROCEDURAL_OPTIMIZATION
+   /prop_tgt/IOS_INSTALL_COMBINED
/prop_tgt/JOB_POOL_COMPILE
/prop_tgt/JOB_POOL_LINK
/prop_tgt/LABELS
diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index 2116900..3f49572 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -257,6 +257,7 @@ Variables that Control the Build
/variable/CMAKE_INSTALL_NAME_DIR
/variable/CMAKE_INSTALL_RPATH
/variable/CMAKE_INSTALL_RPATH_USE_LINK_PATH
+   /variable/CMAKE_IOS_INSTALL_COMBINED
/variable/CMAKE_LANG_COMPILER_LAUNCHER
/variable/CMAKE_LANG_INCLUDE_WHAT_YOU_USE
/variable/CMAKE_LANG_VISIBILITY_PRESET
diff --git a/Help/prop_tgt/IOS_INSTALL_COMBINED.rst 
b/Help/prop_tgt/IOS_INSTALL_COMBINED.rst
new file mode 100644
index 000..59f67a7
--- /dev/null
+++ b/Help/prop_tgt/IOS_INSTALL_COMBINED.rst
@@ -0,0 +1,11 @@
+IOS_INSTALL_COMBINED
+
+
+Build a combined (device and simulator) target when installing.
+
+When this property is set to set to false (which is the default) then it will
+either be built with the device SDK or the simulator SDK depending on the SDK
+set. But if this property is set to true then the target will at install time
+also be built for the corresponding SDK and combined into one library.
+
+This feature requires at least Xcode version 6.
diff --git a/Help/release/dev/ios-universal.rst 
b/Help/release/dev/ios-universal.rst
new file mode 100644
index 000..f96abed
--- /dev/null
+++ b/Help/release/dev/ios-universal.rst
@@ -0,0 +1,7 @@
+ios-universal
+-
+
+* When building for embedded Apple platforms like iOS CMake learned to build 
and
+  install combined targets which contain both a device and a simulator build.
+  This behavior can be enabled by setting the :prop_tgt:`IOS_INSTALL_COMBINED`
+  target property.
diff --git a/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst 
b/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst
new file mode 100644
index 000..c5cb9b6
--- /dev/null
+++ b/Help/variable/CMAKE_IOS_INSTALL_COMBINED.rst
@@ -0,0 +1,8 @@
+CMAKE_IOS_INSTALL_COMBINED
+--
+
+Default value for :prop_tgt:`IOS_INSTALL_COMBINED` of targets.
+
+This variable is used to initialize the :prop_tgt:`IOS_INSTALL_COMBINED`
+property on all the targets.  See that target property for additional
+information.
diff --git a/Modules/CMakeIOSInstallCombined.cmake 
b/Modules/CMakeIOSInstallCombined.cmake
new file mode 100644
index 000..f052a3b
--- /dev/null
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -0,0 +1,297 @@
+

Re: [CMake] Parallel jobs failed for cmake

[Bill Hoffman]

On 12/10/2015 12:19 AM, Igor Sobinov wrote:

igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5
igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd
/home/igor/build_root/release_target; make release
igor 5467 0.0 0.0 101184 1060 pts/3 S+ 08:10 0:00 | \_ make release
Looks like you created the build_release target as a custom command that 
does:

make release

This will strip the -j off of the make process and you get the warning. 
 If you are going to call make recursively like that you have to use 
$(MAKE) so that all the right env stuff gets passed down.  CMake does 
this with its calls to make.


You should be able to do what we do in ExternalProject and use $(MAKE). 
 I would have to see your CMakeLists.txt code and the custom command to 
help more.


-Bill

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Thursday, December 10, 2015 15:26:54 Brad King wrote:
> On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
> >> set(var ON)
> >> option(var "description" OFF)
> >> message("var: ${var}")
> > 
> > I.e. on the first run it would be OFF (since that's the default value
> > of the option), and all later runs it would have the value which is in 
the
> > cache.
> This is calling for the opposite change than Ben's proposal.  Ben
> suggests never unsetting the local value to expose the cached value.
> Alex is suggesting always doing so, even if the cache option is
> not created by the command.
> 
> Alternatively the option() or set(CACHE) commands could also set
> a local variable to the same value as the cache entry.
> 
> This is pretty fundamental behavior so if we are going to mess with
> it through a policy we better get it right.

Yes. :-)

My motivation: if the option() would just set/get the cache variable, and 
leave the local variable untouched, it would be a NOOP in the example 
above, and this is not obvious from seeing that code.

Alex

-- 

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] set(CACHE) and the local scope

[Ben Boeckel]

On Thu, Dec 10, 2015 at 21:20:21 +0100, Alexander Neundorf wrote:
> On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> > So some behavior I was unaware of until today came up:
> > 
> > set(var ON)
> > option(var "description" OFF)
> > message("var: ${var}")
> 
> Assuming I wouldn't know about the subtle characteristics of normal vs. 
> cache variables, I think I would expect that var has the value of the option 
> afterwards.
> 
> I.e. on the first run it would be OFF (since that's the default value of the 
> option), and all later runs it would have the value which is in the cache.

The problem with this behavior is that if I do -Dinternal_var:BOOL=OFF,
it will override any variable of that name inside the project and it
cannot override it without knowing it is in the cache to unset it so
that the local variable is used again.

This behavior also breaks cmake_dependent_option as-is since it sets a
local variable to the fallback value if its requirements are not met
(which is how it remembers the user decision when it becomes a viable
option again).

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Brad King]

On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
>> set(var ON)
>> option(var "description" OFF)
>> message("var: ${var}")
> 
> I.e. on the first run it would be OFF (since that's the default value
> of the option), and all later runs it would have the value which is in the 
> cache.

This is calling for the opposite change than Ben's proposal.  Ben
suggests never unsetting the local value to expose the cached value.
Alex is suggesting always doing so, even if the cache option is
not created by the command.

Alternatively the option() or set(CACHE) commands could also set
a local variable to the same value as the cache entry.

This is pretty fundamental behavior so if we are going to mess with
it through a policy we better get it right.

-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] Forcing CMake to rerun

[Nicholas Clark]

Hi all,

I'm working on using CMake to create a build system that targets an
incredibly hard-to-deal-with IDE/build system, used for doing some embedded
programming (Xilinx's Vivado suite).

One of the pieces I need to get working is a conditional dependency between
two files (a project-file generator script that gets archived in Git, and
the actual project files that get generated).

The graph basically looks like this:

Path 1: .tcl file (in Git) -> .xpr file (used by IDE)
Path 2: .xpr file (after a user changes something in the IDE) -> .tcl file
(needs to be regenerated)

So on any clean build, the source-controlled TCL file autogenerates a bunch
of required project files. On iterative builds at a developer's desk, he
might change some IDE setting and then the TCL file needs to be regenerated
(without triggering a rebuild of the project files as well). It's kind of a
conditional and/or psuedo-circular dependency.

In pure GNU Make, I can express a conditional dependency with an 'if'
statement that uses timestamp checks. It's also easy for me to express this
dependency in CMakeLists.txt - I can check the file timestamps, and I can
conditionally emit the relevant custom_target/custom_rule.

That only works when CMakeLists.txt gets parsed, however. Is there any way
for me to force a CMake-generated Makefile to _always_ rerun CMake before
trying to build the 'all' target? If not, is there any other clever way
that I could express this conditional dependency?

-Nick
-- 

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] Imported targets for FindGTest

[rleigh]

> - Add unit test to test imported targets and existing variables

I should mention that to run the unit test, you must define the GTEST_ROOT
environment variable to point to the gtest build, due to gtest being
annoyingly crippled to be uninstallable for dubious reasons.  You can pass
-DGTEST_ROOT, but since the cmake build can't pass it through without
further changes, the environment variable is the only way to run the test
with the existing patches.


Regards,
Roger

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Imported targets for FindGTest

[rleigh]

> - Adds GTest::GTest and GTest::Main imported targets (including
> Thread::Thread dependency for GTest::GTest and GTest::GTest for
> GTest::Main; the latter might not be appropriate and could be removed if
> needed--but I'm unaware of any situation where you would want to use
> GTest::Main without GTest::GTest)

Double-checking the gtest_main symbol table, it depends on symbols from
gtest, so the dependency is actually required, so please ignore the
above--it's definitely appropriate.

-- 

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.4.1-1698-gd3ccdd3

[Roger Leigh]

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  d3ccdd30915356d716d3de0e56129e6da36bed0e (commit)
   via  99afe23513054db4add5143de4aa3a826e8c6c75 (commit)
   via  611735e76e14807e2145d6b67efbb080d419f19f (commit)
  from  caa83f4e41630cd00e8e32f2330d2c1be045b95f (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=d3ccdd30915356d716d3de0e56129e6da36bed0e
commit d3ccdd30915356d716d3de0e56129e6da36bed0e
Merge: caa83f4 99afe23
Author: Roger Leigh 
AuthorDate: Thu Dec 10 18:11:09 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 18:11:09 2015 -0500

Merge topic 'gtest-imported-targets' into next

99afe235 Tests: Add tests for FindGTest
611735e7 FindGTest: Add imported targets and update documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99afe23513054db4add5143de4aa3a826e8c6c75
commit 99afe23513054db4add5143de4aa3a826e8c6c75
Author: Roger Leigh 
AuthorDate: Thu Dec 10 23:08:23 2015 +
Commit: Roger Leigh 
CommitDate: Thu Dec 10 23:09:16 2015 +

Tests: Add tests for FindGTest

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 5d492cf..65bfb77 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1362,6 +1362,11 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   if(CMake_TEST_FindGSL)
 add_subdirectory(FindGSL)
   endif()
+
+  if(CMake_TEST_FindGTest)
+add_subdirectory(FindGTest)
+  endif()
+
   if(CMake_TEST_FindJsonCpp)
 add_subdirectory(FindJsonCpp)
   endif()
diff --git a/Tests/FindGTest/CMakeLists.txt b/Tests/FindGTest/CMakeLists.txt
new file mode 100644
index 000..cbc92b1
--- /dev/null
+++ b/Tests/FindGTest/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindGTest.Test COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/FindGTest/Test"
+  "${CMake_BINARY_DIR}/Tests/FindGTest/Test"
+  ${build_generator_args}
+  --build-project TestFindGTest
+  --build-options ${build_options}
+  --test-command ${CMAKE_CTEST_COMMAND} -V -C $
+  )
diff --git a/Tests/FindGTest/Test/CMakeLists.txt 
b/Tests/FindGTest/Test/CMakeLists.txt
new file mode 100644
index 000..99368ac
--- /dev/null
+++ b/Tests/FindGTest/Test/CMakeLists.txt
@@ -0,0 +1,17 @@
+cmake_minimum_required(VERSION 3.1)
+project(TestFindGTest CXX)
+include(CTest)
+
+# CMake does not actually provide FindGTest publicly.
+set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/../../../Source/Modules)
+
+find_package(GTest REQUIRED)
+
+add_executable(test_gtest_tgt main.cxx)
+target_link_libraries(test_gtest_tgt GTest::Main)
+add_test(NAME test_gtest_tgt COMMAND test_gtest_tgt)
+
+add_executable(test_gtest_var main.cxx)
+target_include_directories(test_gtest_var PRIVATE ${GTEST_INCLUDE_DIRS})
+target_link_libraries(test_gtest_var PRIVATE ${GTEST_BOTH_LIBRARIES} 
${CMAKE_THREAD_LIBS_INIT})
+add_test(NAME test_gtest_var COMMAND test_gtest_var)
diff --git a/Tests/FindGTest/Test/main.cxx b/Tests/FindGTest/Test/main.cxx
new file mode 100644
index 000..0572a5d
--- /dev/null
+++ b/Tests/FindGTest/Test/main.cxx
@@ -0,0 +1,6 @@
+#include 
+
+TEST(FindCMake, LinksAndRuns)
+{
+  ASSERT_TRUE(true);
+}

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=611735e76e14807e2145d6b67efbb080d419f19f
commit 611735e76e14807e2145d6b67efbb080d419f19f
Author: Roger Leigh 
AuthorDate: Thu Dec 10 15:52:07 2015 +
Commit: Roger Leigh 
CommitDate: Thu Dec 10 23:09:08 2015 +

FindGTest: Add imported targets and update documentation

diff --git a/Modules/FindGTest.cmake b/Modules/FindGTest.cmake
index eb7abfd..ca49e4a 100644
--- a/Modules/FindGTest.cmake
+++ b/Modules/FindGTest.cmake
@@ -4,88 +4,89 @@
 #
 # Locate the Google C++ Testing Framework.
 #
-# Defines the following variables:
+# Imported targets
+# 
 #
-# ::
-#
-#GTEST_FOUND - Found the Google Testing framework
-#GTEST_INCLUDE_DIRS - Include directories
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
+# ``GTest::GTest``
+#   The Google Test ``gtest`` library, if found; adds Thread::Thread
+#   automatically
+# ``GTest::Main``
+#   The Google Test ``gtest_main`` library, if found
 #
 #
-# Also defines the library variables below as normal variables.  These
-# contain debug/optimized keywords when a debugging library is found.
-#
-# ::
+# Result variables
+# 
 #
-#GTEST_BOTH_LIBRARIES - Both libgtest & libgtest-main
-#GTEST_LIBRARIES 

[cmake-developers] [PATCH] Imported targets for FindGTest

[rleigh]

Pushed to

  https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/gtest-
imported-targets

and merged into next for review and testing.

- Adds GTest::GTest and GTest::Main imported targets (including
Thread::Thread dependency for GTest::GTest and GTest::GTest for
GTest::Main; the latter might not be appropriate and could be removed if
needed--but I'm unaware of any situation where you would want to use
GTest::Main without GTest::GTest)
- Document imported targets
- Update documentation, adding sections, description lists and updated
examples
- Add unit test to test imported targets and existing variables


Kind 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] Problem when using variable_watch with Visual Studio generator in 3.4.1

[David Cole via CMake]

Out of curiosity, what output do you get (with 3.4.1) when you comment out
your call to variable_watch? Do you still get error output, but without
strange symbols in it? Or is there no error output in that case?


On Thursday, December 10, 2015, Yves Frederix 
wrote:

> Hi all,
>
> I am experiencing problems during the CMake configure step when using
> the function variable_watch. Consider the following minimal CMakeLists
> file:
>
>   cmake_minimum_required(VERSION 3.4)
>   project(test CXX)
>
>   function(myhook _variable _access _value _current_list_file _stack)
> if("${_value}" STREQUAL "")
>   # Do nothing
> endif()
>   endfunction()
>
>   variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
>   find_package(PythonInterp REQUIRED)
>
>
> When configuring on Windows using CMake 3.4.1 with the Visual Studio
> generator (I tried both VS2012 and VS2015), the process fails with an
> error message (notice the strange symbols at the beginning of the line
> mentioning FindPackageMessage.cmake):
>
>   -- Detecting CXX compile features - done
> CMake Error at
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
> (include):
>   include could not find load file:
>
> L☺/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
> Call Stack (most recent call first):
>   C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
> (include)
>   CMakeLists.txt:12 (find_package)
>
>
>   CMake Error at
>
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
> (FIND_PACKAGE_MESSAGE):
>   Unknown CMake command "FIND_PACKAGE_MESSAGE".
>   Call Stack (most recent call first):
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
> CMakeLists.txt:12 (find_package)
>
>
> I did some more testing, and the configuration step is successful when:
> - using CMake 2.8.12 or 3.4.0
> - using 3.4.1 (or older versions) on osx (I did not try linux)
> - removing the 'CXX' in the project call or removing the project call
> entirely
> - removing the check for _value inside the function
>
> It seems that for some reason adding the watch (which actually only
> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR
> variable is messed up somehow. Could I have run into some corner case
> behavior here?
>
> Maybe it is also useful to mention how I ended up in this situation.
> My requirement was to run some custom code as the very last step of
> the configure process. The solution I found was based on using
> variable_watch (see
>
> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843
> ),
> but apparently this is not a very robust solution. Are there possibly
> better ways of accomplishing the same thing?
>
> Thanks!
>
> Regards,
> Yves
> --
>
> 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-developers] Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 10-Dec-15 13:55, Gregor Jasny wrote:

Hello,

On 09/12/15 10:21, Ruslan Baratov wrote:

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable
IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms.
Other platforms (in future) will be controlled by using *_ARCHITECTURES
variables, right?


Right. Any objections to that property name?

Thanks,
Gregor


TL;DR I'm finding it a little bit confusing but can't propose any better 
alternatives so I have no objections :)


Some thoughts:
* arm64 + armv7 is a universal binary, arm64 + armv7 + i386 - well, 
still universal binary too :)
* OSX_ARCHITECTURES affect architectures on iOS. Probably it should be 
IOS_ARCHITECTURES or just ARCHITECTURES (though MACOSX_BUNDLE works same 
way)
* OSX_ARCHITECTURES=armv7 -> build armv7, OSX_ARCHITECTURES=armv7,arm64 
-> build universal armv7+arm64, but OSX_ARCHITECTURES=armv7,arm64,i386 
doesn't build armv7+arm64+i386 binary
* hard to say anything about future improvements, like if it will be 
easier to implement universal binary in build directory on Android, then 
*_ARCHITECTURES looks better. but if it will be easier to build one 
architecture then add extra code to add more on install then 
INSTALL_UNIVERSAL_BINARY for all platforms looks better


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1

[Yves Frederix]

After commenting out the call there is no error output:

  -- The CXX compiler identification is MSVC 17.0.61030.0
  -- Check for working CXX compiler using: Visual Studio 11 2012 Win64
  -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 --
works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.10")
  -- Configuring done
  -- Generating done


Yves

On Thu, Dec 10, 2015 at 12:58 PM, David Cole  wrote:

> Out of curiosity, what output do you get (with 3.4.1) when you comment out
> your call to variable_watch? Do you still get error output, but without
> strange symbols in it? Or is there no error output in that case?
>
>
> On Thursday, December 10, 2015, Yves Frederix <
> yves.frederix+cm...@gmail.com> wrote:
>
>> Hi all,
>>
>> I am experiencing problems during the CMake configure step when using
>> the function variable_watch. Consider the following minimal CMakeLists
>> file:
>>
>>   cmake_minimum_required(VERSION 3.4)
>>   project(test CXX)
>>
>>   function(myhook _variable _access _value _current_list_file _stack)
>> if("${_value}" STREQUAL "")
>>   # Do nothing
>> endif()
>>   endfunction()
>>
>>   variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
>>   find_package(PythonInterp REQUIRED)
>>
>>
>> When configuring on Windows using CMake 3.4.1 with the Visual Studio
>> generator (I tried both VS2012 and VS2015), the process fails with an
>> error message (notice the strange symbols at the beginning of the line
>> mentioning FindPackageMessage.cmake):
>>
>>   -- Detecting CXX compile features - done
>> CMake Error at
>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
>> (include):
>>   include could not find load file:
>>
>> L☺/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
>> Call Stack (most recent call first):
>>   C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
>> (include)
>>   CMakeLists.txt:12 (find_package)
>>
>>
>>   CMake Error at
>>
>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
>> (FIND_PACKAGE_MESSAGE):
>>   Unknown CMake command "FIND_PACKAGE_MESSAGE".
>>   Call Stack (most recent call first):
>>
>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>> CMakeLists.txt:12 (find_package)
>>
>>
>> I did some more testing, and the configuration step is successful when:
>> - using CMake 2.8.12 or 3.4.0
>> - using 3.4.1 (or older versions) on osx (I did not try linux)
>> - removing the 'CXX' in the project call or removing the project call
>> entirely
>> - removing the check for _value inside the function
>>
>> It seems that for some reason adding the watch (which actually only
>> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR
>> variable is messed up somehow. Could I have run into some corner case
>> behavior here?
>>
>> Maybe it is also useful to mention how I ended up in this situation.
>> My requirement was to run some custom code as the very last step of
>> the configure process. The solution I found was based on using
>> variable_watch (see
>>
>> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843
>> ),
>> but apparently this is not a very robust solution. Are there possibly
>> better ways of accomplishing the same thing?
>>
>> Thanks!
>>
>> Regards,
>> Yves
>> --
>>
>> 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] Problem when using variable_watch with Visual Studio generator in 3.4.1

[Yves Frederix]

Hi all,

I am experiencing problems during the CMake configure step when using
the function variable_watch. Consider the following minimal CMakeLists
file:

  cmake_minimum_required(VERSION 3.4)
  project(test CXX)

  function(myhook _variable _access _value _current_list_file _stack)
if("${_value}" STREQUAL "")
  # Do nothing
endif()
  endfunction()

  variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
  find_package(PythonInterp REQUIRED)


When configuring on Windows using CMake 3.4.1 with the Visual Studio
generator (I tried both VS2012 and VS2015), the process fails with an
error message (notice the strange symbols at the beginning of the line
mentioning FindPackageMessage.cmake):

  -- Detecting CXX compile features - done
CMake Error at 
C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
(include):
  include could not find load file:

L☺/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
Call Stack (most recent call first):
  C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
(include)
  CMakeLists.txt:12 (find_package)


  CMake Error at
C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
(FIND_PACKAGE_MESSAGE):
  Unknown CMake command "FIND_PACKAGE_MESSAGE".
  Call Stack (most recent call first):
C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:12 (find_package)


I did some more testing, and the configuration step is successful when:
- using CMake 2.8.12 or 3.4.0
- using 3.4.1 (or older versions) on osx (I did not try linux)
- removing the 'CXX' in the project call or removing the project call entirely
- removing the check for _value inside the function

It seems that for some reason adding the watch (which actually only
does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR
variable is messed up somehow. Could I have run into some corner case
behavior here?

Maybe it is also useful to mention how I ended up in this situation.
My requirement was to run some custom code as the very last step of
the configure process. The solution I found was based on using
variable_watch (see
http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843),
but apparently this is not a very robust solution. Are there possibly
better ways of accomplishing the same thing?

Thanks!

Regards,
Yves
-- 

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] ExternalProject_Add and inheritance

[Cedric Doucet]

Hello, 

I use the ExternalProject_Add command to manage third-party libraries. 
In the same time, I need to overcome some compatibility problems between GCC 4 
and GCC 5 (strings are not defined in the same way in the STL). 
The solution I use is the one given here: 
http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5 
It allows me to force to use the libstdc++.so given by the GCC repository given 
to the cmake command. 

The problem is that trick does not work with the ExternalProject_Add command 
because configuration steps of third-party libraries are autonomous. 
Do you know how to solve the problem? 

For example, if I use the ExternalProject_Add command to manage a third-library 
whose configuration also depends on a cmake script, how could I tell this 
script to use the compilers and the libstdc++.so I provided to my own cmake 
script? 

Best, 

Cédric 
-- 

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] How to set environment variables with spaces in commands

[Ruslan Baratov via CMake]

On 10-Dec-15 12:52, Attila Krasznahorkay wrote:

Hi QP,

Probably not the intended solution, but what I’m doing in such cases is that in 
a patch step I create a shell script that does the configuration for me. With 
all the environment settings and everything. Like:

PATCH_COMMAND ${CMAKE_COMMAND} -E echo “cd someDir/; CC=\”something\” ./configure” 
> configure.sh
CONFIGURE_COMMAND sh configure.sh

...


Unfortunately this makes the code quite unportable, as it will only work on 
POSIX platforms like this.
Even on *nix platforms such code will not always works as expected. As 
documentation states 
(https://cmake.org/cmake/help/v3.4/module/ExternalProject.html):


   Behavior of shell operators like |&&| is not defined.

I've hit this on practice by using `LOG_* 1` feature. You can try this 
example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no 
LOG_PATCH option):


   https://gist.github.com/ruslo/e8c7be03521f167ae8f0


Result:

   [ 62%] Performing configure step for 'Foo'
   cd /.../Foo-prefix/src/Foo-build && /.../cmake -P
   /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake
   CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16
   (message):
  Command failed: 1

The reason of the failure is because CMake collect all arguments into 
one command and run execute_process:


   set(command "/.../cmake;-E;echo;cd ..;>;configure.sh")
   execute_process(COMMAND ${command} RESULT_VARIABLE result)

which of course doesn't make sense.

This makes writing ExternalProject_Add steps with modification of 
environment quite non-trivial task (at least doing it correctly). This 
feature definitely missing in CMake. I've mentioned it once already: 
https://cmake.org/pipermail/cmake-developers/2015-August/026053.html


but I've changed my mind about the approach because of LOG_* issue. Now 
I do the next:


* wrap each step with CMake script, i.e. instead of `CC=something 
./configure` do


   set(ENV{CC} "something")
   execute_process(COMMAND ./configure ...)

* run CMake script in *_COMMAND:

   CONFIGURE_COMMAND
   "${CMAKE_COMMAND}" -P "/path/to/configure.cmake"

This makes it cross-platform and *_LOG friendly but require more tricks. 
Like if you're building in source (non-cmake packages) you have to copy 
script before execution since CMake will remove source directory on 
DOWNLOAD step. Which makes it looks like this:


   CONFIGURE_COMMAND
   "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake"
   "/path/to/unpacked/configure.cmake"
   COMMAND
   "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake"

PS I'm hitting problems in ExternalProject with environment variables 
all the time. E.g. at this moment fixing MinGW + Boost: 
https://github.com/ruslo/hunter/pull/273


Ruslo


  But I guess that’s the case anyway once you start setting environment 
variables.

Cheers,
Attila

P.S. I often create build.sh and install.sh scripts as well in additional patch 
commands.


On Dec 10, 2015, at 5:35 AM, Qingping Hou  wrote:

Hi all,

I am trying to setup an ExternalProject in cmake but got stuck in the
configuration step. I am using ccache to speed up the compilation:

```
ExternalProject_Add(
  ...
  CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure
  ...
)
```

However, when cmake generates the Makefile, it moves the quotes around
and breaks the command:

```
"CC=ccache arm-linux-gnueabihf-gcc" ./configure
```

I have tried various escaping method to try to get it work properly
without any luck. Is this a bug or an unintended feature?

Thanks,
QP
--

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-commits] CMake branch, next, updated. v3.4.1-1663-gf447ad4

[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  f447ad40b4a155f3501354857aa6cfb36d52 (commit)
   via  7984ac5e58722295e71f6c2418e2a54d6f1a0cc1 (commit)
   via  4ce6fbc76b0ebaeef258695c2b876061b5b61073 (commit)
  from  11039e0002bd03eccaee930d308b1afd5dcf3a9b (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=f447ad40b4a155f3501354857aa6cfb36d52
commit f447ad40b4a155f3501354857aa6cfb36d52
Merge: 11039e0 7984ac5
Author: Brad King 
AuthorDate: Thu Dec 10 09:08:27 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 09:08:27 2015 -0500

Merge topic 'cmake-E-multiple-inputs' into next

7984ac5e cmake: Teach -E make_directory to support multiple input 
directories
4ce6fbc7 Help: Rename release notes for topic 'cmake-E-multiple-inputs'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7984ac5e58722295e71f6c2418e2a54d6f1a0cc1
commit 7984ac5e58722295e71f6c2418e2a54d6f1a0cc1
Author: Bartosz Kosiorek 
AuthorDate: Wed Dec 9 15:59:43 2015 +0100
Commit: Brad King 
CommitDate: Thu Dec 10 09:07:38 2015 -0500

cmake: Teach -E make_directory to support multiple input directories

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 4cbe976..91af3e3 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -167,7 +167,8 @@ Available commands are:
   Change the current working directory and run a command.
 
 ``compare_files  ``
-  Check if file1 is same as file2.
+  Check if  is same as . If files are the same,
+  then returns 0, if not itreturns 1.
 
 ``copy ... ``
   Copy files to  (either file or directory).
@@ -194,10 +195,11 @@ Available commands are:
   Run command in a modified environment.
 
 ``environment``
-  Display the current environment.
+  Display the current environment variables.
 
-``make_directory ``
-  Create a directory.
+``make_directory ...``
+  Create  directories.  If necessary, create parent
+  directories too.
 
 ``md5sum ...``
   Compute md5sum of files.
diff --git a/Help/release/dev/cmake-E-multiple-inputs.rst 
b/Help/release/dev/cmake-E-multiple-inputs.rst
index aa52a98..480261d 100644
--- a/Help/release/dev/cmake-E-multiple-inputs.rst
+++ b/Help/release/dev/cmake-E-multiple-inputs.rst
@@ -6,3 +6,6 @@ cmake-E-multiple-inputs
 
 * The :manual:`cmake(1)` ``-E copy_directory`` command-line
   tool learned to support copying multiple input directories to a directory.
+
+* The :manual:`cmake(1)` ``-E make_directory`` command-line
+  tool learned to support copying multiple input directories to a directory.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 6a4234f..fb7b1f5 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -68,7 +68,7 @@ void CMakeCommandUsage(const char* program)
 << "  env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...\n"
 << "- run command in a modified environment\n"
 << "  environment   - display the current environment\n"
-<< "  make_directory dir- create a directory\n"
+<< "  make_directory ...   - create parent and  directories\n"
 << "  md5sum ...  - compute md5sum of files\n"
 << "  remove [-f] ... - remove the file(s), use -f to force "
"it\n"
@@ -447,15 +447,20 @@ int cmcmd::ExecuteCMakeCommand(std::vector& 
args)
   }
 #endif
 
-else if (args[1] == "make_directory" && args.size() == 3)
+else if (args[1] == "make_directory" && args.size() > 2)
   {
-  if(!cmSystemTools::MakeDirectory(args[2].c_str()))
+  // If error occurs we want to continue copying next files.
+  bool return_value = 0;
+  for (std::string::size_type cc = 2; cc < args.size(); cc ++)
 {
-std::cerr << "Error making directory \"" << args[2]
-  << "\".\n";
-return 1;
+if(!cmSystemTools::MakeDirectory(args[cc].c_str()))
+  {
+  std::cerr << "Error creating directory \""
+<< args[cc] << "\".\n";
+  return_value = 1;
+  }
 }
-  return 0;
+  return return_value;
   }
 
 else if (args[1] == "remove_directory" && args.size() == 3)
diff --git 
a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt 
b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ 
b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
@@ -0,0 +1 @@
+0

Re: [cmake-developers] [PATCH] Support multiple directories by "cmake -E make_directory" command

[Brad King]

On 12/09/2015 03:01 PM, Bartosz Kosiorek wrote:
> support for multiple directories for make_directory command.

Thanks.  Applied with minor documentation tweak:

 cmake: Teach -E make_directory to support multiple input directories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7984ac5e

-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] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory

[Nikita Barawade]

Hi,

getting following error when trying to run LLAPI_TestApp

./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot open 
shared object file: No such file or directory

Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind.


CMakeLists.txt for LLAPI_TestApp :


include_directories (../Include)
include_directories (../../LLAPI/Include)

# collect all cpp files
file (GLOB ALL_SOURCES
"*.cpp")

# Adds sources to the Solution Explorer
add_executable ( LLAPI_TestApp  ${ALL_SOURCES})

target_link_libraries (LLAPI_TestApp   LLAPI)

install (TARGETS LLAPI_TestApp
RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind)

set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)


Searched whole day on Internet but could not fix it .

Pls guide


Regards,
Nikita
*
 eInfochips Business Disclaimer: This e-mail message and all attachments 
transmitted with it are intended solely for the use of the addressee and may 
contain legally privileged and confidential information. If the reader of this 
message is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited. If you have received this message in error, 
please notify the sender immediately by replying to this message and please 
delete it from your computer. Any views expressed in this message are those of 
the individual sender unless otherwise stated. Company has taken enough 
precautions to prevent the spread of viruses. However the company accepts no 
liability for any damage caused by any virus transmitted by this email. 
*
-- 

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] How to set environment variables with spaces in commands

[Attila Krasznahorkay]

Hi Ruslan,

Thanks, this is good to know.

I absolutely agree that one needs to avoid using "&&" in the commands 
themselves. As it also causes problems when you try to use 
CTEST_USE_LAUNCHERS=1. (I myself ran into that issue...)

But I did not have any issues so far with putting "whatever" into a shell 
script that I then later execute. This is how I got around not being able to 
use wildcards in some installation commands for instance.

However, I quite like your solution of using a CMake script instead of a *nix 
shell one. As that should be indeed much more portable. Even if my current 
project will not work on Windows for a lot of reasons anyway...

Cheers,
  Attila

> On 10 Dec 2015, at 13:38, Ruslan Baratov  wrote:
> 
> On 10-Dec-15 12:52, Attila Krasznahorkay wrote:
>> Hi QP,
>> 
>> Probably not the intended solution, but what I’m doing in such cases is that 
>> in a patch step I create a shell script that does the configuration for me. 
>> With all the environment settings and everything. Like:
>> 
>> PATCH_COMMAND ${CMAKE_COMMAND} -E echo “cd someDir/; CC=\”something\” 
>> ./configure” > configure.sh
>> CONFIGURE_COMMAND sh configure.sh
>> 
> ...
> 
>> Unfortunately this makes the code quite unportable, as it will only work on 
>> POSIX platforms like this.
> Even on *nix platforms such code will not always works as expected. As 
> documentation states 
> (https://cmake.org/cmake/help/v3.4/module/ExternalProject.html):
> Behavior of shell operators like && is not defined.
> I've hit this on practice by using `LOG_* 1` feature. You can try this 
> example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no 
> LOG_PATCH option):
> 
> https://gist.github.com/ruslo/e8c7be03521f167ae8f0
> 
> Result:
> [ 62%] Performing configure step for 'Foo'
> cd /.../Foo-prefix/src/Foo-build && /.../cmake -P 
> /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake
> CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16 
> (message):
>   Command failed: 1
> The reason of the failure is because CMake collect all arguments into one 
> command and run execute_process:
> set(command "/.../cmake;-E;echo;cd ..;>;configure.sh")
> execute_process(COMMAND ${command} RESULT_VARIABLE result)
> which of course doesn't make sense.
> 
> This makes writing ExternalProject_Add steps with modification of environment 
> quite non-trivial task (at least doing it correctly). This feature definitely 
> missing in CMake. I've mentioned it once already: 
> https://cmake.org/pipermail/cmake-developers/2015-August/026053.html
> 
> but I've changed my mind about the approach because of LOG_* issue. Now I do 
> the next:
> 
> * wrap each step with CMake script, i.e. instead of `CC=something 
> ./configure` do
> set(ENV{CC} "something")
> execute_process(COMMAND ./configure ...)
> * run CMake script in *_COMMAND:
> 
> CONFIGURE_COMMAND
> "${CMAKE_COMMAND}" -P "/path/to/configure.cmake"
> This makes it cross-platform and *_LOG friendly but require more tricks. Like 
> if you're building in source (non-cmake packages) you have to copy script 
> before execution since CMake will remove source directory on DOWNLOAD step. 
> Which makes it looks like this:
> 
> CONFIGURE_COMMAND
> "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake" 
> "/path/to/unpacked/configure.cmake"
> COMMAND
> "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake"
> 
> PS I'm hitting problems in ExternalProject with environment variables all the 
> time. E.g. at this moment fixing MinGW + Boost: 
> https://github.com/ruslo/hunter/pull/273
> 
> Ruslo
> 
>>  But I guess that’s the case anyway once you start setting environment 
>> variables.
>> 
>> Cheers,
>>Attila
>> 
>> P.S. I often create build.sh and install.sh scripts as well in additional 
>> patch commands.
>> 
>> 
>>> On Dec 10, 2015, at 5:35 AM, Qingping Hou 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I am trying to setup an ExternalProject in cmake but got stuck in the
>>> configuration step. I am using ccache to speed up the compilation:
>>> 
>>> ```
>>> ExternalProject_Add(
>>>  ...
>>>  CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure
>>>  ...
>>> )
>>> ```
>>> 
>>> However, when cmake generates the Makefile, it moves the quotes around
>>> and breaks the command:
>>> 
>>> ```
>>> "CC=ccache arm-linux-gnueabihf-gcc" ./configure
>>> ```
>>> 
>>> I have tried various escaping method to try to get it work properly
>>> without any luck. Is this a bug or an unintended feature?
>>> 
>>> Thanks,
>>> QP
>>> -- 
>>> 
>>> Powered by 
>>> www.kitware.com
>>> 
>>> 
>>> Please keep messages on-topic and check the CMake FAQ at: 
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>> 
>>> 
>>> Kitware offers various services to support the CMake community. For more 
>>> information on each offering, please visit:
>>> 
>>> CMake Support: 
>>> http://cmake.org/cmake/help/support.html
>>> 
>>> CMake Consulting: 
>>> 

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[Brad King]

On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote:
> I identify the root of the problem: if I specify version 3.4 in
> cmake_minimum_required, generated link command (stored in file link.txt)
> for an executable does not contains value specified in variable
> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem.
> So this is a regression introduced in 3.4.

It is not technically a backward incompatibility because project code
that worked in 3.3 will still work the same way in 3.4.  Only after
modifying the code to require 3.4 does the behavior change, but the
new behavior is a regression.  This is policy CMP0065:

 https://cmake.org/cmake/help/v3.4/policy/CMP0065.html

introduced here:

 CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b

The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended
to be equivalent to "-rdynamic" on Linux, but the AIX platform file
is using it for other flags too:

> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall")

This should be just

 set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall")

and the `-Wl,-brtl,-bnoipath` flags should move elsewhere.  One could
add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line,
for example.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Ok. I see the problem. Thanks for your investigation.
I will work on that and submit a patch to solve this problem.

Marc





On 10/12/15 14:42, "Brad King"  wrote:

>On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote:
>> I identify the root of the problem: if I specify version 3.4 in
>> cmake_minimum_required, generated link command (stored in file link.txt)
>> for an executable does not contains value specified in variable
>> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem.
>> So this is a regression introduced in 3.4.
>
>It is not technically a backward incompatibility because project code
>that worked in 3.3 will still work the same way in 3.4.  Only after
>modifying the code to require 3.4 does the behavior change, but the
>new behavior is a regression.  This is policy CMP0065:
>
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
>
>introduced here:
>
> CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b
>
>The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended
>to be equivalent to "-rdynamic" on Linux, but the AIX platform file
>is using it for other flags too:
>
>> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall")
>
>This should be just
>
> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall")
>
>and the `-Wl,-brtl,-bnoipath` flags should move elsewhere.  One could
>add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line,
>for example.
>
>Thanks,
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Brad King]

On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")
> 
> outputs "OFF" for the first configure and "ON" for subsequent
> configures. This is because set(var CACHE) does unset(var) *if* the
> cache was touched. This is not done on the second time around since it
> is already in the cache.

That is a long-standing subtlety introduced without discussion, review,
or tests here:

 BUG: change in how set cache overrides local definitions. Should mainly be a 
NOP change for most cases
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2

IIRC there was confusion at the time in the case of

 set(var 1)
 set(var 2 CACHE STRING ...)
 message("${var}") # prints "1" before the above change.

> I think a policy to remove the unset(var) behavior should be added since
> the current behavior means that clean builds can be wildly different
> than incremental builds.

One reason a policy has not been introduced for this before is that
producing a warning for the policy may be very verbose unless it is
delayed until variable dereference, but the latter would be a huge
performance hit to check.  Still, I think things would be better off
in the long run with some policy for it.

> Related, I have a branch on the stage (update-variable-docs) which
> attempts to clarify some darker corners of the set() command and the
> *VARIABLES directory properties.

The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places.
The release note should only cover the new feature.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ExternalProject_Add and inheritance

[CHEVRIER, Marc]

With CMake, you can control compilation and link flags with the following 
environment variables:

  *   CC: specify C compiler
  *   CFLAGS: C compiler flags
  *   CXX: specify C++ compiler
  *   CXXFLAGS: C++ compiler flags
  *   LDFLAGS: linker flags

And to finish you can overload make command for generation using CMAKE_COMMAND 
option of ExternalProject_Add:
CMAKE_CMMAND “${CMAKE_COMMAND}” -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=“…” 
“${CMAKE_COMMAND}”



From: CMake > on behalf 
of Cedric Doucet >
Date: Thursday 10 December 2015 at 18:21
To: "cmake@cmake.org" 
>
Subject: [CMake] ExternalProject_Add and inheritance


Hello,

I use the ExternalProject_Add command to manage third-party libraries.
In the same time, I need to overcome some compatibility problems between GCC 4 
and GCC 5 (strings are not defined in the same way in the STL).
The solution I use is the one given here:
http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5
It allows me to force to use the libstdc++.so given by the GCC repository given 
to the cmake command.

The problem is that trick does not work with the ExternalProject_Add command 
because configuration steps of third-party libraries are autonomous.
Do you know how to solve the problem?

For example, if I use the ExternalProject_Add command to manage a third-library 
whose configuration also depends on a cmake script, how could I tell this 
script to use the compilers and the libstdc++.so I provided to my own cmake 
script?

Best,

Cédric
-- 

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] Add Clang support to FindOpenMP

[Chris Pavlina]

Hi,

Attached is a patch to add the correct option for building OpenMP code using 
Clang. Per the llvm release notes 
 it is 
necessary to give -fopenmp=libomp to build properly, not just -fopenmp. Tested 
on 64-bit Linux using clang 3.7.0.

Chris

>From f80164de4b51afc7cdcc053346c696ea2baaa4a4 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Thu, 10 Dec 2015 10:40:27 -0500
Subject: [PATCH] Add Clang support to FindOpenMP

---
 Modules/FindOpenMP.cmake | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake
index a102c66..ee4bdd6 100644
--- a/Modules/FindOpenMP.cmake
+++ b/Modules/FindOpenMP.cmake
@@ -50,6 +50,8 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
 " "
 #GNU
 "-fopenmp"
+#Clang
+"-fopenmp=libomp"
 #Microsoft Visual Studio
 "/openmp"
 #Intel windows
@@ -67,6 +69,7 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
   )
 
   set(OMP_FLAG_GNU "-fopenmp")
+  set(OMP_FLAG_Clang "-fopenmp=libomp")
   set(OMP_FLAG_HP "+Oopenmp")
   if(WIN32)
 set(OMP_FLAG_Intel "-Qopenmp")
-- 
2.6.4

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015877]: Performance regression in file generation

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15877 
== 
Reported By:Jim King
Assigned To:
== 
Project:CMake
Issue ID:   15877
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-11 00:50 EST
Last Modified:  2015-12-11 00:50 EST
== 
Summary:Performance regression in file generation
Description: 
There was a significant performance regression between CMake 2.8 and 3.4
between "-- Configuring done" and "--Generating done" phases.  We have a rather
large project with a number of files and here are the timing results:

CMake-3.4

39.27user 10.14system 0:50.62elapsed 97%CPU (0avgtext+0avgdata
119384maxresident)k
40inputs+167408outputs (0major+254266minor)pagefaults 0swaps

CMake-2.8

21.97user 8.09system 0:32.09elapsed 93%CPU (0avgtext+0avgdata
163040maxresident)k
8400inputs+172200outputs (30major+266779minor)pagefaults 0swaps

We're generating on Ubuntu 14.04 LTS with the command:
CC=clang CXX=clang++ time /usr/bin/cmake -G"Eclipse CDT4 - Unix Makefiles"

I could not find a defect for this so I decided to add one.

Steps to Reproduce: 
See description.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-11 00:50 Jim King   New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-669-g693abba

[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  693abba25176d073ab3073e7920f4aa8929cc6e0 (commit)
  from  fc6c5074e800fb7fe3f829564d7a7e284133cdd9 (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=693abba25176d073ab3073e7920f4aa8929cc6e0
commit 693abba25176d073ab3073e7920f4aa8929cc6e0
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Dec 11 00:01:17 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Dec 11 00:01:17 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fab29ab..6c6ba32 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 4)
-set(CMake_VERSION_PATCH 20151210)
+set(CMake_VERSION_PATCH 20151211)
 #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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1675-gd9556ec

[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  d9556ecb53c6a34736fee6c2b58c360203fcabd9 (commit)
   via  fc6c5074e800fb7fe3f829564d7a7e284133cdd9 (commit)
   via  a657b324822b5bd549706b337a74fa3bfd7bc1c6 (commit)
  from  b40c3f77caad27321aa570fd59b1e63ea972ea4d (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=d9556ecb53c6a34736fee6c2b58c360203fcabd9
commit d9556ecb53c6a34736fee6c2b58c360203fcabd9
Merge: b40c3f7 fc6c507
Author: Brad King 
AuthorDate: Thu Dec 10 09:30:28 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 09:30:28 2015 -0500

Merge branch 'master' into next


---

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


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1667-g91798eb

[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  91798eb761176a082e692411e981404474f48276 (commit)
   via  e0ad72d8af9bfba80d24f823d79440ebb9136bda (commit)
  from  28552384b40e9516073bcd099fd5f73679578c80 (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=91798eb761176a082e692411e981404474f48276
commit 91798eb761176a082e692411e981404474f48276
Merge: 2855238 e0ad72d
Author: Brad King 
AuthorDate: Thu Dec 10 09:22:34 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 09:22:34 2015 -0500

Merge topic 'graphviz-spaces' into next

e0ad72d8 Graphviz: Fix handling of spaces in GRAPHVIZ_GRAPH_NAME


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e0ad72d8af9bfba80d24f823d79440ebb9136bda
commit e0ad72d8af9bfba80d24f823d79440ebb9136bda
Author: Andrey Mishchenko 
AuthorDate: Wed Dec 9 12:15:52 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 09:22:06 2015 -0500

Graphviz: Fix handling of spaces in GRAPHVIZ_GRAPH_NAME

Without this patch, `SET (GRAPHVIZ_GRAPH_NAME "hello world")` does not
work (it results in a parsing error in GraphViz when the generated
output is processed), but `SET (GRAPHVIZ_GRAPH_NAME "\"hello world\"")`
does.

diff --git a/Source/cmGraphVizWriter.cxx b/Source/cmGraphVizWriter.cxx
index a63b6e3..448306f 100644
--- a/Source/cmGraphVizWriter.cxx
+++ b/Source/cmGraphVizWriter.cxx
@@ -292,7 +292,7 @@ void cmGraphVizWriter::WriteGlobalFile(const char* fileName)
 
 void cmGraphVizWriter::WriteHeader(cmGeneratedFileStream& str) const
 {
-  str << this->GraphType << " " << this->GraphName << " {" << std::endl;
+  str << this->GraphType << " \"" << this->GraphName << "\" {" << std::endl;
   str << this->GraphHeader << std::endl;
 }
 

---

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


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-668-gfc6c507

[Brad King]

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

The branch, master has been updated
   via  fc6c5074e800fb7fe3f829564d7a7e284133cdd9 (commit)
   via  d462ac27d814e966c54bb638444e4b125d1d665f (commit)
  from  a657b324822b5bd549706b337a74fa3bfd7bc1c6 (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=fc6c5074e800fb7fe3f829564d7a7e284133cdd9
commit fc6c5074e800fb7fe3f829564d7a7e284133cdd9
Merge: a657b32 d462ac2
Author: Brad King 
AuthorDate: Thu Dec 10 09:30:14 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 09:30:14 2015 -0500

Merge topic 'cmELF-use-KWIML'

d462ac27 cmELF: Use KWIML ABI.h header to get endian-ness


---

Summary of changes:
 Source/cmELF.cxx |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)


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

[cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Hello.


With CMake 3.5 it is possible to put Resources into the Bundle (Frameworks and 
Applications)


More information:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/prop_tgt/RESOURCE.rst


So with code:

  add_executable(ExecutableTarget
addDemo.c
resourcefile.txt
appresourcedir/appres.txt
  )

  target_link_libraries(ExecutableTarget heymath mul)

  set(RESOURCE_FILES
resourcefile.txt
appresourcedir/appres.txt
  )

  set_target_properties(ExecutableTarget PROPERTIES
MACOSX_BUNDLE TRUE
MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
RESOURCE "${RESOURCE_FILES}"
  )

For OS X systems it will produce following directory structure::

  ExecutableTarget.app/
Contents
  Info.plist
  MacOS
ExecutableTarget
  Resources
appres.txt
resourcefile.txt


How it is officialy supported to tell CMake to create subdirectories inside 
"Resources" directory?


As the result I would like to get, following directory structure:

  ExecutableTarget.app/
Contents/
  Info.plist
  MacOS/
ExecutableTarget
  Resources/
appres.txt?

appresourcedir/

   ?resourcefile.txt?


I would like to update documentation to describe how to do that.


Thanks in advance

Bartosz

-- 

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.4.1-1672-gb40c3f7

[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  b40c3f77caad27321aa570fd59b1e63ea972ea4d (commit)
   via  291275347be3f9c02aff6fb4dfa45a3e5b2f5b4a (commit)
   via  67211011d946684bed73bcd5b976ec90f4c30856 (commit)
  from  75501ddf13fcfcef4f59de31d0cfdbd3665640f2 (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=b40c3f77caad27321aa570fd59b1e63ea972ea4d
commit b40c3f77caad27321aa570fd59b1e63ea972ea4d
Merge: 75501dd 2912753
Author: Brad King 
AuthorDate: Thu Dec 10 09:28:53 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 09:28:53 2015 -0500

Merge topic 'cmake-W-options' into next

29127534 cmake: Deduplicate warning message control code
67211011 cmake-gui: Add options to control warning messages


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=291275347be3f9c02aff6fb4dfa45a3e5b2f5b4a
commit 291275347be3f9c02aff6fb4dfa45a3e5b2f5b4a
Author: Michael Scott 
AuthorDate: Sun Dec 6 12:58:24 2015 +
Commit: Brad King 
CommitDate: Thu Dec 10 09:28:31 2015 -0500

cmake: Deduplicate warning message control code

Remove the duplicate code in cmake::Configure to set the cache variables
for the warning message suppression.  Replace it with calls to the
dedicated methods to carry this out.

diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index e57e512..7992495 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -1269,17 +1269,11 @@ int cmake::Configure()
 diagLevel = this->DiagLevels["deprecated"];
 if (diagLevel == DIAG_IGNORE)
   {
-  this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
-  "Whether to issue warnings for deprecated "
-  "functionality.",
-  cmState::INTERNAL);
+  this->SetSuppressDeprecatedWarnings(true);
   }
 else if (diagLevel == DIAG_WARN)
   {
-  this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE",
-  "Whether to issue warnings for deprecated "
-  "functionality.",
-  cmState::INTERNAL);
+  this->SetSuppressDeprecatedWarnings(false);
   }
 }
 
@@ -1299,32 +1293,20 @@ int cmake::Configure()
 diagLevel = this->DiagLevels["dev"];
 if (diagLevel == DIAG_IGNORE)
   {
-  this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "TRUE",
-  "Suppress Warnings that are meant for"
-  " the author of the CMakeLists.txt files.",
-  cmState::INTERNAL);
+  this->SetSuppressDevWarnings(true);
 
   if (setDeprecatedVariables)
 {
-this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "FALSE",
-"Whether to issue warnings for deprecated "
-"functionality.",
-cmState::INTERNAL);
+this->SetSuppressDeprecatedWarnings(true);
 }
   }
 else if (diagLevel == DIAG_WARN)
   {
-  this->AddCacheEntry("CMAKE_SUPPRESS_DEVELOPER_WARNINGS", "FALSE",
-  "Suppress Warnings that are meant for"
-  " the author of the CMakeLists.txt files.",
-  cmState::INTERNAL);
+  this->SetSuppressDevWarnings(false);
 
   if (setDeprecatedVariables)
 {
-this->AddCacheEntry("CMAKE_WARN_DEPRECATED", "TRUE",
-"Whether to issue warnings for deprecated "
-"functionality.",
-cmState::INTERNAL);
+this->SetSuppressDeprecatedWarnings(false);
 }
   }
 }
@@ -2881,6 +2863,24 @@ void cmake::RunCheckForUnusedVariables()
 #endif
 }
 
+bool cmake::GetSuppressDevWarnings(cmMakefile const* mf)
+{
+  /*
+   * The suppression CMake variable may be set in the CMake configuration file
+   * itself, so we have to check what its set to in the makefile if we can.
+   */
+  if (mf)
+{
+return mf->IsOn("CMAKE_SUPPRESS_DEVELOPER_WARNINGS");
+}
+  else
+{
+const char* cacheEntryValue = this->State->GetCacheEntryValue(
+  "CMAKE_SUPPRESS_DEVELOPER_WARNINGS");
+return cmSystemTools::IsOn(cacheEntryValue);
+}
+}
+
 void cmake::SetSuppressDevWarnings(bool b)
 {
   std::string value;
@@ -2902,24 +2902,6 @@ void cmake::SetSuppressDevWarnings(bool b)
   cmState::INTERNAL);
 }
 
-bool cmake::GetSuppressDevWarnings(cmMakefile const* mf)
-{
-  /*
-   * The 

Re: [cmake-developers] set(CACHE) and the local scope

[Ben Boeckel]

On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
> That is a long-standing subtlety introduced without discussion, review,
> or tests here:
> 
>  BUG: change in how set cache overrides local definitions. Should mainly be a 
> NOP change for most cases
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2
> 
> IIRC there was confusion at the time in the case of
> 
>  set(var 1)
>  set(var 2 CACHE STRING ...)
>  message("${var}") # prints "1" before the above change.

The above commit has the same behavior as it does today: first configure
!= subsequent configure, so I don't see the confusion as being *less*
after the fix since any existing tree wouldn't say "2" either, but I
suppose it was something about dashboards doing clean builds.

> On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> > I think a policy to remove the unset(var) behavior should be added since
> > the current behavior means that clean builds can be wildly different
> > than incremental builds.
> 
> One reason a policy has not been introduced for this before is that
> producing a warning for the policy may be very verbose unless it is
> delayed until variable dereference, but the latter would be a huge
> performance hit to check.  Still, I think things would be better off
> in the long run with some policy for it.

Like with some of the more disruptive policies (e.g., CMP0054), it's a
clarification of some potentially^Wconfusing behavior which can bite you
in certain cases pretty hard (CI vs. developer builds).

> The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places.
> The release note should only cover the new feature.

Oops. Updated. Also reordered the branch so the feature is at the end of
the branch.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory

[Kornel Benko]

Am Donnerstag, 10. Dezember 2015 um 12:38:11, schrieb Nikita Barawade 

> 
> Hi,
> 
> getting following error when trying to run LLAPI_TestApp
> 
> ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot 
> open shared object file: No such file or directory
> 
> Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind.
> 
> 
> CMakeLists.txt for LLAPI_TestApp :
> 
> 
> include_directories (../Include)
> include_directories (../../LLAPI/Include)
> 
> # collect all cpp files
> file (GLOB ALL_SOURCES
> "*.cpp")
> 
> # Adds sources to the Solution Explorer
> add_executable ( LLAPI_TestApp  ${ALL_SOURCES})
> 
> target_link_libraries (LLAPI_TestApp   LLAPI)
> 
> install (TARGETS LLAPI_TestApp
> RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind)
> 
> set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ")
> set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> 
> 
> Searched whole day on Internet but could not fix it .
> 
> Pls guide
> 

And where is your call to create the library?
e.g.
add_library(LLAPI ${lib_sources})
?

> Regards,
> Nikita

Kornel


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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1680-g3c09aff

[Nils Gladitz]

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  3c09aff91048787b6d3a019b36a81e1bd3a8562f (commit)
   via  ecdc77f14d7a37f9d173ea2ca4946bf51c6a43d0 (commit)
  from  d94e61ab747b1eb3e8209a8e6011cbd4926122db (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=3c09aff91048787b6d3a019b36a81e1bd3a8562f
commit 3c09aff91048787b6d3a019b36a81e1bd3a8562f
Merge: d94e61a ecdc77f
Author: Nils Gladitz 
AuthorDate: Thu Dec 10 10:39:38 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 10:39:38 2015 -0500

Merge topic 'wix-fix-comp-install-prop' into next

ecdc77f1 CPackWIX: Fix installed file property lookups when using components


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecdc77f14d7a37f9d173ea2ca4946bf51c6a43d0
commit ecdc77f14d7a37f9d173ea2ca4946bf51c6a43d0
Author: Nils Gladitz 
AuthorDate: Thu Dec 10 17:38:18 2015 +0100
Commit: Nils Gladitz 
CommitDate: Thu Dec 10 17:38:18 2015 +0100

CPackWIX: Fix installed file property lookups when using components

The WIX generator incorrectly looked for installed file properties
by relative paths that included the component specific staging
directory prefix.

Remove that prefix in installed file property lookups when
generating packages with components.

diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index d5246db..da8b486 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -911,8 +911,9 @@ void cmCPackWIXGenerator::AddDirectoryAndFileDefinitons(
 relativeDirectoryPath = ".";
 }
 
-  cmInstalledFile const* directoryInstalledFile =
-this->GetInstalledFile(relativeDirectoryPath);
+  cmInstalledFile const* directoryInstalledFile = this->GetInstalledFile(
+  this->RelativePathWithoutComponentPrefix(relativeDirectoryPath)
+  );
 
   bool emptyDirectory = dir.GetNumberOfFiles() == 2;
   bool createDirectory = false;
@@ -980,8 +981,9 @@ void cmCPackWIXGenerator::AddDirectoryAndFileDefinitons(
   }
 else
   {
-  cmInstalledFile const* installedFile =
-this->GetInstalledFile(relativePath);
+  cmInstalledFile const* installedFile = this->GetInstalledFile(
+this->RelativePathWithoutComponentPrefix(relativePath)
+  );
 
   if(installedFile)
 {
@@ -1230,3 +1232,16 @@ void cmCPackWIXGenerator::AddCustomFlags(
   stream << " " << QuotePath(*i);
 }
 }
+
+std::string cmCPackWIXGenerator::RelativePathWithoutComponentPrefix(
+  std::string const& path)
+{
+  if(this->Components.empty())
+{
+return path;
+}
+
+  std::string::size_type pos = path.find('/');
+
+  return path.substr(pos + 1);
+}
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.h 
b/Source/CPack/WiX/cmCPackWIXGenerator.h
index d501609..3f66b2c 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.h
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.h
@@ -168,6 +168,9 @@ private:
   void AddCustomFlags(
 std::string const& variableName, std::ostream& stream);
 
+  std::string RelativePathWithoutComponentPrefix(
+std::string const& path);
+
   std::vector WixSources;
   id_map_t PathToIdMap;
   ambiguity_map_t IdAmbiguityCounter;

---

Summary of changes:
 Source/CPack/WiX/cmCPackWIXGenerator.cxx |   23 +++
 Source/CPack/WiX/cmCPackWIXGenerator.h   |3 +++
 2 files changed, 22 insertions(+), 4 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1678-gd94e61a

[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  d94e61ab747b1eb3e8209a8e6011cbd4926122db (commit)
   via  c025e61ad47513d63c4b09a2267d254229c13c2e (commit)
   via  2b7a47d76ac5289acc1572917b8ac8266ffec0ca (commit)
  from  d9556ecb53c6a34736fee6c2b58c360203fcabd9 (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=d94e61ab747b1eb3e8209a8e6011cbd4926122db
commit d94e61ab747b1eb3e8209a8e6011cbd4926122db
Merge: d9556ec c025e61
Author: Brad King 
AuthorDate: Thu Dec 10 10:19:52 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 10:19:52 2015 -0500

Merge topic 'update-kwsys' into next

c025e61a Merge branch 'upstream-kwsys' into update-kwsys
2b7a47d7 KWSys 2015-12-09 (cdcf4c47)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c025e61ad47513d63c4b09a2267d254229c13c2e
commit c025e61ad47513d63c4b09a2267d254229c13c2e
Merge: fc6c507 2b7a47d
Author: Brad King 
AuthorDate: Thu Dec 10 09:33:14 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 09:33:14 2015 -0500

Merge branch 'upstream-kwsys' into update-kwsys


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b7a47d76ac5289acc1572917b8ac8266ffec0ca
commit 2b7a47d76ac5289acc1572917b8ac8266ffec0ca
Author: KWSys Robot 
AuthorDate: Wed Dec 9 11:45:28 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 09:32:49 2015 -0500

KWSys 2015-12-09 (cdcf4c47)

Extract upstream KWSys using the following shell commands.

$ git archive --prefix=upstream-kwsys/ cdcf4c47 | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 6bfc1aef..cdcf4c47
Brad King (2):
  452b10d5 FundamentalType: Drop KWSYS_CAN_CONVERT_UI64_TO_DOUBLE macro
  cdcf4c47 Drop the CPU.h component of KWSys

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ce7f563..b859e79 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -124,7 +124,6 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
   SET(KWSYS_USE_FStream 1)
   SET(KWSYS_USE_String 1)
   SET(KWSYS_USE_SystemInformation 1)
-  SET(KWSYS_USE_CPU 1)
 ENDIF()
 
 # Enforce component dependencies.
@@ -425,13 +424,6 @@ IF(KWSYS_USE_FundamentalType)
 ENDIF()
   ENDFOREACH()
 
-  IF(KWSYS_USE___INT64)
-KWSYS_PLATFORM_CXX_TEST(KWSYS_CAN_CONVERT_UI64_TO_DOUBLE
-  "Checking whether unsigned __int64 can convert to double" DIRECT)
-  ELSE()
-SET(KWSYS_CAN_CONVERT_UI64_TO_DOUBLE 1)
-  ENDIF()
-
   # Check signedness of "char" type.
   KWSYS_PLATFORM_CXX_TEST_RUN(KWSYS_CHAR_IS_SIGNED
 "Checking whether char is signed" DIRECT)
@@ -749,7 +741,7 @@ ENDFOREACH()
 
 # Add selected C components.
 FOREACH(c
-Process Base64 Encoding FundamentalType MD5 Terminal System String CPU
+Process Base64 Encoding FundamentalType MD5 Terminal System String
 )
   IF(KWSYS_USE_${c})
 # Use the corresponding header file.
diff --git a/CPU.h.in b/CPU.h.in
deleted file mode 100644
index 66ffbb1..000
--- a/CPU.h.in
+++ /dev/null
@@ -1,141 +0,0 @@
-/*
-  KWSys - Kitware System Library
-  Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
-
-  Distributed under the OSI-approved BSD License (the "License");
-  see accompanying file Copyright.txt for details.
-
-  This software is distributed WITHOUT ANY WARRANTY; without even the
-  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-  See the License for more information.
-*/
-#ifndef @KWSYS_NAMESPACE@_CPU_h
-#define @KWSYS_NAMESPACE@_CPU_h
-
-#include <@KWSYS_NAMESPACE@/Configure.h>
-
-/* Identify possible endian cases.  The macro
-   @KWSYS_NAMESPACE@_CPU_ENDIAN_ID will be defined to one of these, or
-   0 if unknown.  */
-#define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID_BIG4321
-#define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID_LITTLE 1234
-
-/* Apple always defines one of these.  */
-#if defined(__LITTLE_ENDIAN__)
-# define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID @KWSYS_NAMESPACE@_CPU_ENDIAN_ID_LITTLE
-#elif defined(__BIG_ENDIAN__)
-# define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID @KWSYS_NAMESPACE@_CPU_ENDIAN_ID_BIG
-
-/* Alpha */
-#elif defined(__alpha) || defined(__alpha__) || defined(_M_ALPHA)
-# define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID @KWSYS_NAMESPACE@_CPU_ENDIAN_ID_LITTLE
-
-/* Arm */
-#elif defined(__arm__)
-# if !defined(__ARMEB__)
-#  define @KWSYS_NAMESPACE@_CPU_ENDIAN_ID 

[CMake] Visual Studio 10 and wxWidgets

[Mauro Ziliani]

Hi all.
I'm in trouble with wxWidgets 3 and Visual Studio 10 express.

I need to change the type of libraries depending on the  configuration
compiler

If I compile in debug mode I need wxbase30ud.lib, while in release mode
wxbase30u

But if I generate the project for VS2010Express the  wxbase30u.lib is
always linked.

How can I setup my CMakeLists to have wxbase30ud when I build Debug and
wxbase30u in Release?

Thanks to all in advance.

MZ
-- 

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.4.1-1682-g987c2cf

[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  987c2cf1d8ae76df4bf5bfc93745d898f981bff7 (commit)
   via  e4b7c4e3c9ab8d95c41d9c8fac4d06cfc7407625 (commit)
  from  3c09aff91048787b6d3a019b36a81e1bd3a8562f (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=987c2cf1d8ae76df4bf5bfc93745d898f981bff7
commit 987c2cf1d8ae76df4bf5bfc93745d898f981bff7
Merge: 3c09aff e4b7c4e
Author: Brad King 
AuthorDate: Thu Dec 10 11:20:13 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 10 11:20:13 2015 -0500

Merge topic 'simplify-CTest.UpdateGIT-test' into next

e4b7c4e3 Tests: Simplify CTest.UpdateGIT repo path construction


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b7c4e3c9ab8d95c41d9c8fac4d06cfc7407625
commit e4b7c4e3c9ab8d95c41d9c8fac4d06cfc7407625
Author: Brad King 
AuthorDate: Thu Dec 10 11:16:11 2015 -0500
Commit: Brad King 
CommitDate: Thu Dec 10 11:18:45 2015 -0500

Tests: Simplify CTest.UpdateGIT repo path construction

Avoid constructing full paths to .git repositories in the test.  Use
relative paths and let Git convert them to absolute paths internally.
This is simpler and also avoids trouble with various absolute path root
component conventions on Windows (`c:/`, `/c/`, `/cygdrive/c/`).

diff --git a/Tests/CTestUpdateGIT.cmake.in b/Tests/CTestUpdateGIT.cmake.in
index 6488a1f..4731f9e 100644
--- a/Tests/CTestUpdateGIT.cmake.in
+++ b/Tests/CTestUpdateGIT.cmake.in
@@ -41,7 +41,6 @@ run_child(
   COMMAND ${GIT} --bare init
   )
 file(REMOVE_RECURSE ${TOP}/repo.git/hooks)
-set(REPO file://${TOP}/repo.git)
 
 # Create submodule repository.
 message("Creating submodule...")
@@ -51,17 +50,13 @@ run_child(
   COMMAND ${GIT} --bare init
   )
 file(REMOVE_RECURSE ${TOP}/module.git/hooks)
-set(MOD_REPO file://${TOP}/module.git)
-create_content(module)
-run_child(WORKING_DIRECTORY ${TOP}/module
-  COMMAND ${GIT} init
+run_child(WORKING_DIRECTORY ${TOP}
+  COMMAND ${GIT} clone module.git module
   )
 file(REMOVE_RECURSE ${TOP}/module/.git/hooks)
 file(APPEND ${TOP}/module/.git/config "
-[remote \"origin\"]
-\turl = ${MOD_REPO}
-\tfetch = +refs/heads/*:refs/remotes/origin/*
 ${AUTHOR_CONFIG}")
+create_content(module)
 run_child(WORKING_DIRECTORY ${TOP}/module
   COMMAND ${GIT} add .
   )
@@ -85,9 +80,6 @@ run_child(WORKING_DIRECTORY ${TOP}/import
   )
 file(REMOVE_RECURSE ${TOP}/import/.git/hooks)
 file(APPEND ${TOP}/import/.git/config "
-[remote \"origin\"]
-\turl = ${REPO}
-\tfetch = +refs/heads/*:refs/remotes/origin/*
 ${AUTHOR_CONFIG}")
 run_child(WORKING_DIRECTORY ${TOP}/import
   COMMAND ${GIT} add .
@@ -96,13 +88,13 @@ run_child(WORKING_DIRECTORY ${TOP}/import
   COMMAND ${GIT} config core.safecrlf false
   )
 run_child(WORKING_DIRECTORY ${TOP}/import
-  COMMAND ${GIT} submodule add ${MOD_REPO} module
+  COMMAND ${GIT} submodule add ../module.git module
   )
 run_child(WORKING_DIRECTORY ${TOP}/import
   COMMAND ${GIT} commit -m "Initial content"
   )
 run_child(WORKING_DIRECTORY ${TOP}/import
-  COMMAND ${GIT} push origin master:refs/heads/master
+  COMMAND ${GIT} push ../repo.git master:refs/heads/master
   )
 
 #-
@@ -123,7 +115,7 @@ run_child(WORKING_DIRECTORY ${TOP}/module
 message("Checking out revision 1...")
 run_child(
   WORKING_DIRECTORY ${TOP}
-  COMMAND ${GIT} clone ${REPO} user-source
+  COMMAND ${GIT} clone repo.git user-source
   )
 file(REMOVE_RECURSE ${TOP}/user-source/.git/hooks)
 file(APPEND ${TOP}/user-source/.git/config "${AUTHOR_CONFIG}")
@@ -278,7 +270,7 @@ set(CTEST_GIT_COMMAND \"${GIT}\")
 set(CTEST_GIT_UPDATE_OPTIONS)
 execute_process(
   WORKING_DIRECTORY \"${TOP}\"
-  COMMAND \"${GIT}\" clone \"${REPO}\" dash-source
+  COMMAND \"${GIT}\" clone repo.git dash-source
   )
 
 # Test .git file.

---

Summary of changes:
 Tests/CTestUpdateGIT.cmake.in |   22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)


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

Re: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory

[J Decker]

is '.' in your LD_LIBRARY_PATH and/or /etc/ld.config?

otherwise 'LD_LIBRARY_PATH=. ./LLAPI_TestApp' should work... or export
LD_LIBRARY_PATH=. for a more semi-permanent solution?

On Thu, Dec 10, 2015 at 4:38 AM, Nikita Barawade
 wrote:
>
>
> Hi,
>
> getting following error when trying to run LLAPI_TestApp
>
> ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot
> open shared object file: No such file or directory
>
> Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind.
>
>
> CMakeLists.txt for LLAPI_TestApp :
>
>
> include_directories (../Include)
> include_directories (../../LLAPI/Include)
>
> # collect all cpp files
> file (GLOB ALL_SOURCES
> "*.cpp")
>
> # Adds sources to the Solution Explorer
> add_executable ( LLAPI_TestApp  ${ALL_SOURCES})
>
> target_link_libraries (LLAPI_TestApp   LLAPI)
>
> install (TARGETS LLAPI_TestApp
> RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind)
>
> set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ")
> set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>
>
> Searched whole day on Internet but could not fix it .
>
> Pls guide
>
>
> Regards,
> Nikita
> *
> eInfochips Business Disclaimer: This e-mail message and all attachments
> transmitted with it are intended solely for the use of the addressee and may
> contain legally privileged and confidential information. If the reader of
> this message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution, copying, or other use
> of this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any views
> expressed in this message are those of the individual sender unless
> otherwise stated. Company has taken enough precautions to prevent the spread
> of viruses. However the company accepts no liability for any damage caused
> by any virus transmitted by this email.
> *
>
> --
>
> 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