date:20151207

Re: [CMake] CMake and a simple java example

2015-12-07 Thread CHEVRIER, Marc

Hi,

You didn’t specify nothing in variable JAVA_SOURCE_DIRECTORY, so java source 
path is effectively /HelloWorld.java.

By the way, you can specify relative paths to the CMakeLists.txt directory for 
java sources, so:

set(JAVA_SOURCE_FILES HelloWorld.java)
add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})

Should do the work.


Or alternately:

set(JAVA_SOURCE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java)
add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})

is also OK.






On 07/12/15 22:52, "CMake on behalf of Kristian"  wrote:

>Dear All,
>
>I am learning CMake, and one of my personal lessons is combine Java
>and CMake. I made a small example (HelloWorld.java):
>
>==
>
>public class HelloWorld
>{
>   public static void main(String[] args)
>   {
>  System.out.println("Hey :)");
>   }
>}
>
>==
>
>And a CMakeLists.txt file:
>
>==
>
>cmake_minimum_required(VERSION 2.8)
>project(HelloWorld)
>
>find_package(Java REQUIRED)
>include(UseJava)
>
>set(JAR_NAME HelloWorld)
>set(JAVA_SOURCE_DIRECTORY )
>set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java)
>add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})
>
>==
>
>Then I go into that directory where the CMakeLists.txt is and start the command
>
>==
>cmake --target=HelloWorld --build .
>==
>
>Output is:
>
>==
>
>-- The C compiler identification is GNU 4.8.4
>-- The CXX compiler identification is GNU 4.8.4
>-- Check for working C compiler: /usr/bin/cc
>-- Check for working C compiler: /usr/bin/cc -- works
>-- Detecting C compiler ABI info
>-- Detecting C compiler ABI info - done
>-- Check for working CXX compiler: /usr/bin/c++
>-- Check for working CXX compiler: /usr/bin/c++ -- works
>-- Detecting CXX compiler ABI info
>-- Detecting CXX compiler ABI info - done
>-- Found Java: /usr/bin/java (found version "1.8.0.66")
>-- Jar file /home/some/Downloads/HelloWorld/HelloWorld.jar
>-- Class compiled to /home/some/Downloads/HelloWorld/CMakeFiles/HelloWorld.dir
>-- Configuring done
>-- Generating done
>-- Build files have been written to: /home/some/Downloads/HelloWorld
>
>==
>
>But when I start the command "make", then I get the following output:
>
>==
>
>Scanning dependencies of target HelloWorld
>make[2]: *** No rule to make target `/HelloWorld.java', needed by
>`CMakeFiles/HelloWorld.dir/java_compiled_HelloWorld'.  Stop.
>make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2
>make: *** [all] Error 2
>
>==
>
>Can you tell me, what I am doing wrong?
>-- 
>
>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] Problems with transitive dependencies

2015-12-07 Thread Mueller-Roemer, Johannes Sebastian

You are evaluating those properties at the wrong time. Transitive properties 
are not passed on at configure time (they can’t be), but at generation time. 
Therefore to debug those values you will have to use generator expressions 
(except they don’t work for link_libraries). Or just look at the generated 
project…

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Wilson
Sent: Monday, December 07, 2015 20:43
To: cmake@cmake.org
Subject: [CMake] Problems with transitive dependencies

Dear CMake users,

I'm trying to use CMake to replace the complex hand-built Visual Studio 
configuration of our open source project, Box Backup. And I'm having trouble 
making it generate the correct transitive dependencies between modules, 
particularly for include directories.

We have a lot of modules whose header files need to be part of the public 
interface to link to these modules. I thought from the manual that "The usage 
requirements of a target can transitively propagate to dependents" but I can't 
make it work (for anything except link libraries).

Here is a toy example taken from the manual:

add_library(archive archive.cpp)
target_compile_definitions(archive PUBLIC USING_ARCHIVE_LIB)

add_library(serialization serialization.cpp)
target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB)

add_library(archiveExtras extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)
target_link_libraries(archiveExtras PRIVATE serialization)
# archiveExtras is compiled with -DUSING_ARCHIVE_LIB
# and -DUSING_SERIALIZATION_LIB

add_executable(consumer consumer.cpp)
# consumer is compiled with -DUSING_ARCHIVE_LIB
target_link_libraries(consumer archiveExtras)

My understanding is that the target_compile_definitions are part of the public 
interface of the archive module, and should be added to anything that links to 
it, which archiveExtras does. But if I add some debugging messages after the 
above code:

foreach (lib archive serialization archiveExtras consumer)
  get_property(ill TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
  get_property(ll TARGET ${lib} PROPERTY LINK_LIBRARIES)
  get_property(icd TARGET ${lib} PROPERTY INTERFACE_COMPILE_DEFINITIONS)
  get_property(cd TARGET ${lib} PROPERTY COMPILE_DEFINITIONS)
  message(STATUS "${lib}: INTERFACE_LINK_LIBRARIES = \"${ill}\" "
"LINK_LIBRARIES = \"${ll}\"")
  message(STATUS "${lib}: INTERFACE_COMPILE_DEFINITIONS = \"${icd}\" "
"COMPILE_DEFINITIONS = \"${cd}\"")
endforeach()

I can see that archiveExtras inherits the link libraries of archive, but not 
its compile_definitions (nor the include directories if I try to inherit them 
instead):

-- archive: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- archive: INTERFACE_COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" 
COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB"

-- serialization: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- serialization: INTERFACE_COMPILE_DEFINITIONS = "USING_SERIALIZATION_LIB" 
COMPILE_DEFINITIONS = ""

-- archiveExtras: INTERFACE_LINK_LIBRARIES = 
"archive;$" LINK_LIBRARIES = "archive;serialization"
-- archiveExtras: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = ""

-- consumer: INTERFACE_LINK_LIBRARIES = "archiveExtras" LINK_LIBRARIES = 
"archiveExtras"
-- consumer: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = ""

The COMPILE_DEFINITIONS of archiveExtras is empty; it has not inherited 
anything.

The manual says:

Because archive is a PUBLIC dependency of archiveExtras, the usage requirements 
of it are propagated to consumer too. Because serialization is a PRIVATE 
dependency of archive, the usage requirements of it are not propagated to 
consumer...

"Usage requirements are propagated by reading the INTERFACE_ variants of target 
properties from dependencies and appending the values to the non-INTERFACE_ 
variants of the operand. For example, the INTERFACE_INCLUDE_DIRECTORIES of 
dependencies is read and appended to the INCLUDE_DIRECTORIES of the operand."

I would assume that the same happens for COMPILE_DEFINITIONS: it should be 
copied from the INTERFACE_COMPILE_DEFINITIONS of the dependencies. But this 
doesn't appear to be happening, as far as I can tell. Nor is the "consumer 
compiled with -DUSING_ARCHIVE_LIB", contrary to the comment (at least it's not 
in the COMPILE_DEFINITIONS).

Can anyone tell me what I'm doing wrong? Specifiying "dependencies" the wrong 
way? I would really appreciate some help :) Do I have to hard-code or script 
all the transitive dependencies myself, or is there something I'm missing?

Thanks in advance, Chris.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check

Re: [CMake] 3.4.1 installer overwrites Windows PATH system var

2015-12-07 Thread Brad King

On 12/04/2015 02:12 AM, Vasily Vladimirovich Vylkov wrote:
> Thanks all -- that worked.  The key:
>   regedit.exe --> HKLM\SYSTEM\ControlSet001\Control\Environment\Path
> 
> had a backup of the path var before the CMake install nuked it.
> 
>> How long was your PATH before?
> 
> Just my luck, it was 1028 chars long (just 4 over the threshold).

Thanks.  That is consistent with my hypothesis.  I'm glad you got it
restored (thanks Tamás!).

> Extremely unpleasant from a user perspective.

Yes.  We will look at addressing this for the 3.5 release now that we
understand the cause.

On 12/04/2015 02:13 AM, Vasily Vladimirovich Vylkov wrote:
>
> Do you run it on a machine with PATH set to a string >1024 chars long?

No, so that is why we haven't noticed it.

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-647-g8cc5e2c

2015-12-07 Thread 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  8cc5e2cb87cc0b2868f10015688991f257371755 (commit)
   via  384ae5514e423fccb02e48a4da25e1549556d898 (commit)
   via  0be5020bf814efd040f7dcd35cc3a9f07d113458 (commit)
  from  939792fdf6d16e192566b1e661725a8a72d6bc7d (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=8cc5e2cb87cc0b2868f10015688991f257371755
commit 8cc5e2cb87cc0b2868f10015688991f257371755
Merge: 939792f 384ae55
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:51 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:51 2015 -0500

Merge topic 'cmake-E-copy-multiple-inputs'

384ae551 cmake: Teach -E copy[_if_different] to support multiple files 
(#15703)
0be5020b cmake: Improve '-E' help message formatting


---

Summary of changes:
 Help/manual/cmake.1.rst|   12 ++--
 Help/release/dev/cmake-E-copy-multiple-inputs.rst  |5 ++
 Source/cmcmd.cxx   |   73 ++--
 Tests/RunCMake/CommandLine/E-no-arg-stderr.txt |2 +-
 ...ource-directory-target-is-directory-result.txt} |0
 ...source-directory-target-is-directory-stderr.txt |0
 .../E_copy-one-source-file-result.txt} |0
 .../CommandLine/E_copy-one-source-file-stderr.txt  |1 +
 ...ee-source-files-target-is-directory-result.txt} |0
 ...ree-source-files-target-is-directory-stderr.txt |0
 ...y-three-source-files-target-is-file-result.txt} |0
 ...py-three-source-files-target-is-file-stderr.txt |1 +
 ...ad-source-files-target-is-directory-result.txt} |0
 ...bad-source-files-target-is-directory-stderr.txt |1 +
 ...ource-directory-target-is-directory-result.txt} |0
 ...source-directory-target-is-directory-stderr.txt |0
 ...ee-source-files-target-is-directory-result.txt} |0
 ...ree-source-files-target-is-directory-stderr.txt |0
 ...t-three-source-files-target-is-file-result.txt} |0
 ...nt-three-source-files-target-is-file-stderr.txt |1 +
 .../CommandLine/E_create_symlink-no-arg-stderr.txt |2 +-
 .../CommandLine/E_rename-no-arg-stderr.txt |2 +-
 .../CommandLine/E_touch_nocreate-no-arg-stderr.txt |2 +-
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake  |   23 ++
 .../RunCMake/CommandLine/copy_input/f1.txt |0
 .../RunCMake/CommandLine/copy_input/f2.txt |0
 .../RunCMake/CommandLine/copy_input/f3.txt |0
 27 files changed, 94 insertions(+), 31 deletions(-)
 create mode 100644 Help/release/dev/cmake-E-copy-multiple-inputs.rst
 copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt => 
CommandLine/E_copy-one-source-directory-target-is-directory-result.txt} (100%)
 copy Modules/IntelVSImplicitPath/hello.f => 
Tests/RunCMake/CommandLine/E_copy-one-source-directory-target-is-directory-stderr.txt
 (100%)
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
CommandLine/E_copy-one-source-file-result.txt} (100%)
 create mode 100644 Tests/RunCMake/CommandLine/E_copy-one-source-file-stderr.txt
 copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt => 
CommandLine/E_copy-three-source-files-target-is-directory-result.txt} (100%)
 copy Modules/IntelVSImplicitPath/hello.f => 
Tests/RunCMake/CommandLine/E_copy-three-source-files-target-is-directory-stderr.txt
 (100%)
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
CommandLine/E_copy-three-source-files-target-is-file-result.txt} (100%)
 create mode 100644 
Tests/RunCMake/CommandLine/E_copy-three-source-files-target-is-file-stderr.txt
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
CommandLine/E_copy-two-good-and-one-bad-source-files-target-is-directory-result.txt}
 (100%)
 create mode 100644 
Tests/RunCMake/CommandLine/E_copy-two-good-and-one-bad-source-files-target-is-directory-stderr.txt
 copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt => 
CommandLine/E_copy_if_different-one-source-directory-target-is-directory-result.txt}
 (100%)
 copy Modules/IntelVSImplicitPath/hello.f => 
Tests/RunCMake/CommandLine/E_copy_if_different-one-source-directory-target-is-directory-stderr.txt
 (100%)
 copy Tests/RunCMake/{CMP0022/CMP0022-WARN-empty-old-result.txt => 
CommandLine/E_copy_if_different-three-source-files-target-is-directory-result.txt}
 (100%)
 copy Modules/IntelVSImplicitPath/hello.f => 
Tests/RunCMake/CommandLine/E_copy_if_different-three-source-files-target-is-directory-stderr.txt
 (100%)
 copy

[Cmake-commits] CMake branch, master, updated. v3.4.1-649-gd9bbc8f

2015-12-07 Thread 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  d9bbc8f02b8374d258c254b2e105b951620d795a (commit)
   via  71e5f253f9b035be7049f36dab2e942220ff6209 (commit)
  from  8cc5e2cb87cc0b2868f10015688991f257371755 (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=d9bbc8f02b8374d258c254b2e105b951620d795a
commit d9bbc8f02b8374d258c254b2e105b951620d795a
Merge: 8cc5e2c 71e5f25
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:54 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:54 2015 -0500

Merge topic 'find-ftn-by-default'

71e5f253 Fortran: Add ftn, the Cray compiler wrapper, to the default search.


---

Summary of changes:
 Modules/CMakeDetermineFortranCompiler.cmake |2 ++
 1 file changed, 2 insertions(+)


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-651-g128d569

2015-12-07 Thread 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  128d569af02d95e455b5ee1d8dddec07251b7033 (commit)
   via  ebaca6290d2c0be7dec22452389632949a700d28 (commit)
  from  d9bbc8f02b8374d258c254b2e105b951620d795a (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=128d569af02d95e455b5ee1d8dddec07251b7033
commit 128d569af02d95e455b5ee1d8dddec07251b7033
Merge: d9bbc8f ebaca62
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:56 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:56 2015 -0500

Merge topic 'FindTIFF-imported-targets'

ebaca629 FindTIFF: Add imported targets and update documentation


---

Summary of changes:
 Help/release/dev/FindTIFF-imported-targets.rst |4 ++
 Modules/FindTIFF.cmake |   67 
 Tests/CMakeLists.txt   |4 ++
 Tests/{FindBoost => FindTIFF}/CMakeLists.txt   |8 +--
 Tests/FindTIFF/Test/CMakeLists.txt |   17 ++
 Tests/FindTIFF/Test/main.c |   12 +
 6 files changed, 98 insertions(+), 14 deletions(-)
 create mode 100644 Help/release/dev/FindTIFF-imported-targets.rst
 copy Tests/{FindBoost => FindTIFF}/CMakeLists.txt (54%)
 create mode 100644 Tests/FindTIFF/Test/CMakeLists.txt
 create mode 100644 Tests/FindTIFF/Test/main.c


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-639-gc3bb76d

2015-12-07 Thread 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  c3bb76dfd2bc732acb8d69ef47dacce9a55a6582 (commit)
   via  56c11eee13604e163eb5a5d9092df405be0e9a5c (commit)
  from  335314e35f5bbfe4131895e9e877e4a19cd3e806 (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=c3bb76dfd2bc732acb8d69ef47dacce9a55a6582
commit c3bb76dfd2bc732acb8d69ef47dacce9a55a6582
Merge: 335314e 56c11ee
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:43 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:43 2015 -0500

Merge topic 'UseJava-relative-manifest'

56c11eee UseJava: Allow relative path to manifest file just as with other 
sources


---

Summary of changes:
 Modules/UseJava.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, master, updated. v3.4.1-637-g335314e

2015-12-07 Thread 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  335314e35f5bbfe4131895e9e877e4a19cd3e806 (commit)
   via  d8b251e2ea84e612dc30a1c9690a8b299aeb30fd (commit)
  from  eda493a38021f439b08807bb8202bab29e79635d (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=335314e35f5bbfe4131895e9e877e4a19cd3e806
commit 335314e35f5bbfe4131895e9e877e4a19cd3e806
Merge: eda493a d8b251e
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:39 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:39 2015 -0500

Merge topic 'fix-java-idlj-jarsigner-typos'

d8b251e2 FindJava: Fix typos in IdlJ and JarSigner component implementation


---

Summary of changes:
 Modules/FindJava.cmake |6 +++---
 1 file changed, 3 insertions(+), 3 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-1635-g279b421

2015-12-07 Thread 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  279b421bf8e42a41b5afee9a05916fe08e278f70 (commit)
   via  128d569af02d95e455b5ee1d8dddec07251b7033 (commit)
   via  d9bbc8f02b8374d258c254b2e105b951620d795a (commit)
   via  8cc5e2cb87cc0b2868f10015688991f257371755 (commit)
   via  939792fdf6d16e192566b1e661725a8a72d6bc7d (commit)
   via  8ff907113792d4554b2837afa7102427572997d1 (commit)
   via  c3bb76dfd2bc732acb8d69ef47dacce9a55a6582 (commit)
   via  335314e35f5bbfe4131895e9e877e4a19cd3e806 (commit)
   via  eda493a38021f439b08807bb8202bab29e79635d (commit)
   via  5609ba1bcd4803547dfbb558d8de3c3d3af6369c (commit)
   via  2c03215050fee3695e7ed9362f35dff1ea9c3016 (commit)
  from  2dd7af2fb8a24af0e03608de327342abc0d49db6 (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=279b421bf8e42a41b5afee9a05916fe08e278f70
commit 279b421bf8e42a41b5afee9a05916fe08e278f70
Merge: 2dd7af2 128d569
Author: Brad King 
AuthorDate: Mon Dec 7 09:23:18 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 7 09:23:18 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, master, updated. v3.4.1-644-g939792f

2015-12-07 Thread 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  939792fdf6d16e192566b1e661725a8a72d6bc7d (commit)
   via  306e2016bb3e285fcfb58e0f17657dc228b67812 (commit)
   via  d5d90f5ec8792fafbe754e2c943825267f7aaff1 (commit)
  from  8ff907113792d4554b2837afa7102427572997d1 (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=939792fdf6d16e192566b1e661725a8a72d6bc7d
commit 939792fdf6d16e192566b1e661725a8a72d6bc7d
Merge: 8ff9071 306e201
Author: Brad King 
AuthorDate: Mon Dec 7 09:22:48 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:22:48 2015 -0500

Merge topic 'update-kwsys'

306e2016 Merge branch 'upstream-kwsys' into update-kwsys
d5d90f5e KWSys 2015-12-03 (6bfc1aef)


---

Summary of changes:
 Source/kwsys/SystemTools.cxx |   26 ++
 Source/kwsys/testSystemTools.cxx |  188 ++
 2 files changed, 197 insertions(+), 17 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-1640-g270a1ae

2015-12-07 Thread 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  270a1aef1c938e7683fb338075c6db432c50bc0e (commit)
   via  bc35087da3eb9039dad8fb5d27c1fab60b43f776 (commit)
   via  98be140fc0dc0bab8955c4fea9274ea52ac8cd9c (commit)
   via  93cc80aee59cfb328d541ba527d40239ab8348b1 (commit)
   via  0903812b0b8c325913d766b793bbf9438ad6b423 (commit)
  from  279b421bf8e42a41b5afee9a05916fe08e278f70 (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=270a1aef1c938e7683fb338075c6db432c50bc0e
commit 270a1aef1c938e7683fb338075c6db432c50bc0e
Merge: 279b421 bc35087
Author: Brad King 
AuthorDate: Mon Dec 7 10:52:54 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 10:52:54 2015 -0500

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

bc35087d cmake: Teach -E copy_directory to support multiple input 
directories
98be140f cmake: Refine -E copy[_if_different] documentation
93cc80ae cmake: Refine -E copy_if_different implementation indentation
0903812b cmake: Refine -E chdir documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc35087da3eb9039dad8fb5d27c1fab60b43f776
commit bc35087da3eb9039dad8fb5d27c1fab60b43f776
Author: Bartosz Kosiorek 
AuthorDate: Sun Dec 6 20:30:44 2015 +0100
Commit: Brad King 
CommitDate: Mon Dec 7 10:51:27 2015 -0500

cmake: Teach -E copy_directory to support multiple input directories

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index d5e8505..4cbe976 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -174,8 +174,9 @@ Available commands are:
   If multiple files are specified, the  must be
   directory and it must exist.
 
-``copy_directory  ``
-  Copy directory 'source' content to directory 'destination'.
+``copy_directory ... ``
+  Copy directories to  directory.
+  If  directory does not exist it will be created.
 
 ``copy_if_different ... ``
   Copy files to  (either file or directory) if
diff --git a/Help/release/dev/cmake-E-copy-multiple-inputs.rst 
b/Help/release/dev/cmake-E-copy-multiple-inputs.rst
index 798af53..eeb1fab 100644
--- a/Help/release/dev/cmake-E-copy-multiple-inputs.rst
+++ b/Help/release/dev/cmake-E-copy-multiple-inputs.rst
@@ -3,3 +3,6 @@ cmake-E-copy-multiple-inputs
 
 * The :manual:`cmake(1)` ``-E copy`` and ``-E copy_if_different`` command-line
   tools learned to support copying multiple input files to a directory.
+
+* The :manual:`cmake(1)` ``-E copy_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 c823201..6a4234f 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -58,8 +58,8 @@ void CMakeCommandUsage(const char* program)
 << "  compare_files file1 file2 - check if file1 is same as file2\n"
 << "  copy ... destination  - copy files to destination "
"(either file or directory)\n"
-<< "  copy_directory source destination   - copy directory 'source' "
-   "content to directory 'destination'\n"
+<< "  copy_directory ... destination   - copy content of ... "
+   "directories to 'destination' directory\n"
 << "  copy_if_different ... destination  - copy files if it has "
"changed\n"
 << "  echo [...]- displays arguments as text\n"
@@ -206,16 +206,22 @@ int cmcmd::ExecuteCMakeCommand(std::vector& 
args)
   }
 
 // Copy directory content
-if (args[1] == "copy_directory" && args.size() == 4)
+if (args[1] == "copy_directory" && args.size() > 3)
   {
-  if(!cmSystemTools::CopyADirectory(args[2], args[3]))
+  // If error occurs we want to continue copying next files.
+  bool return_value = 0;
+  for (std::string::size_type cc = 2; cc < args.size() - 1; cc ++)
 {
-std::cerr << "Error copying directory from \""
-  << args[2] << "\" to \"" << args[3]
-  << "\".\n";
-return 1;
+if(!cmSystemTools::CopyADirectory(args[cc].c_str(),
+args[args.size() - 1].c_str()))
+  {
+  std::cerr << "Error copying directory from \""
+<< args[cc] << "\" to \"" << args[args.size() - 1]
+<< "\".\n";
+  return_value = 1;
+  }
 }
-  return 0;
+  return return_value;
   }
 
 // Rename a file or directory
diff --git 
a/Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-directory-result.txt

[Cmake-commits] CMake branch, next, updated. v3.4.1-1624-g2dd7af2

2015-12-07 Thread 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  2dd7af2fb8a24af0e03608de327342abc0d49db6 (commit)
   via  ebaca6290d2c0be7dec22452389632949a700d28 (commit)
  from  995642cbf6d47366c3d24285a9d2120b569d3527 (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=2dd7af2fb8a24af0e03608de327342abc0d49db6
commit 2dd7af2fb8a24af0e03608de327342abc0d49db6
Merge: 995642c ebaca62
Author: Brad King 
AuthorDate: Mon Dec 7 09:21:10 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 09:21:10 2015 -0500

Merge topic 'FindTIFF-imported-targets' into next

ebaca629 FindTIFF: Add imported targets and update documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ebaca6290d2c0be7dec22452389632949a700d28
commit ebaca6290d2c0be7dec22452389632949a700d28
Author: Roger Leigh 
AuthorDate: Wed Dec 2 17:20:24 2015 +
Commit: Brad King 
CommitDate: Mon Dec 7 09:20:08 2015 -0500

FindTIFF: Add imported targets and update documentation

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
  target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
  TIFF_INCLUDE_DIRS

diff --git a/Help/release/dev/FindTIFF-imported-targets.rst 
b/Help/release/dev/FindTIFF-imported-targets.rst
new file mode 100644
index 000..f8bbc14
--- /dev/null
+++ b/Help/release/dev/FindTIFF-imported-targets.rst
@@ -0,0 +1,4 @@
+FindTIFF-imported-targets
+-
+
+* The :module:`FindTIFF` module now provides imported targets.
diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index ed092ea..e600498 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -2,24 +2,43 @@
 # FindTIFF
 # 
 #
-# Find TIFF library
+# Find the TIFF library (libtiff).
 #
-# Find the native TIFF includes and library This module defines
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-#   TIFF_INCLUDE_DIR, where to find tiff.h, etc.
-#   TIFF_LIBRARIES, libraries to link against to use TIFF.
-#   TIFF_FOUND, If false, do not try to use TIFF.
+# ``TIFF::TIFF``
+#   The TIFF library, if found.
 #
-# also defined, but not for general use are
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   TIFF_LIBRARY, where to find the TIFF library.
+# ``TIFF_FOUND``
+#   true if the TIFF headers and libraries were found
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_INCLUDE_DIRS``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARIES``
+#   TIFF libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARY``
+#   the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -65,7 +84,35 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(TIFF
   VERSION_VAR TIFF_VERSION_STRING)
 
 if(TIFF_FOUND)
-  set( TIFF_LIBRARIES ${TIFF_LIBRARY} )
+  set(TIFF_LIBRARIES ${TIFF_LIBRARY})
+  set(TIFF_INCLUDE_DIRS "${TIFF_INCLUDE_DIR}")
+
+  if(NOT TARGET TIFF::TIFF)
+add_library(TIFF::TIFF UNKNOWN IMPORTED)
+if(TIFF_INCLUDE_DIRS)
+  set_target_properties(TIFF::TIFF PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${TIFF_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${TIFF_LIBRARY}")
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+IMPORTED_LOCATION "${TIFF_LIBRARY}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_DEBUG}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
+IMPORTED_LOCATION_DEBUG "${TIFF_LIBRARY_DEBUG}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_RELEASE}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS RELEASE)
+  set_target_properties(TIFF::TIFF PROPERTIES
+

Re: [CMake] MPI wrappers vs FindMPI

2015-12-07 Thread Zaak Beekman

Thanks for the insight Brad.

Another advantage may be that the FindMPI module knows about what `mpirun`
or `mpiexec` is called, as well as some common flags, like number of ranks
to execute. Since OpenCoarrays writes an MPI compiler wrapper script and a
script to run the executable, `caf` and `cafrun`, using FindMPI could also
help reduce the overhead of knowing about different MPI implementations and
their peculiarities; this task would effectively be delighted to FindMPI...

Damian,
I'll poke around in the CMake code and we can discuss this on Friday.

Thanks again,
-Zaak

On Mon, Dec 7, 2015 at 8:56 AM Brad King  wrote:

> On 12/04/2015 05:51 PM, Zaak Beekman wrote:
> > What are the pros and cons of using FindMPI over passing FC=mpif90 and
> CC=mpicc?
>
> It shouldn't matter much if all the code in the project is meant
> to be build for MPI.  Using plain FindMPI with the CC/CXX/FC set
> to the system compilers is cleaner for building only a subset of
> targets for MPI.  FindMPI will look for the MPI compilers separately
> in order to ask them for the proper flags to tell the system compiler
> how to use MPI, and then project CMake code can take responsibility
> for applying that information to the desired subset of its targets.
> Using CC=mpicc, FindMPI will recognize that the C compiler is already
> a MPI compiler and not bother to look for a separate one to query
> the settings (and similarly for C++ and Fortran).
>
> -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

Re: [CMake] Control the build target's external dependencies

2015-12-07 Thread Attila Krasznahorkay

Just to answer myself: After looking at the source code, I now understand that 
the regular expression set by include_regular_expression(...) is not compared 
against the full path name of the included file, but just what's in the source 
file after #include. So this machinery is non too useful for me at the moment.

For now I patched CMake locally with the following to ignore all out of source 
files in the dependency generation for me. With:

diff -u -r orig/cmake-3.4.1/Source/cmDepends.cxx 
cmake-3.4.1/Source/cmDepends.cxx
--- orig/cmake-3.4.1/Source/cmDepends.cxx   2015-12-02 16:43:21.0 
+0100
+++ cmake-3.4.1/Source/cmDepends.cxx2015-12-07 13:59:07.039749715 +0100
@@ -18,6 +18,7 @@
 #include "cmFileTimeComparison.h"
 #include 
 #include 
+#include 
 
 //
 cmDepends::cmDepends(cmLocalGenerator* lg, const char* targetDir):
@@ -291,6 +292,13 @@
   return okay;
 }
 
+// Helper predicate for removing absolute paths from the include directory
+// list.
+bool IsAbsolutePath( const std::string& path )
+{
+  return cmSystemTools::FileIsFullPath( path );
+}
+
 //
 void cmDepends::SetIncludePathFromLanguage(const std::string& lang)
 {
@@ -317,4 +325,8 @@
   cmSystemTools::ExpandListArgument(includePath, this->IncludePath);
   }
 }
+  // Remove all absolute paths from the dependency evaluation:
+  auto itr = std::remove_if( this->IncludePath.begin(), 
this->IncludePath.end(),
+ IsAbsolutePath );
+  this->IncludePath.erase( itr, this->IncludePath.end() );
 }

(Could be implemented with slightly fewer lines as well.)

Which sped up the generation of these depend.make files immensely. So I wonder 
if turning on this behaviour could be a new thing in the future. As I imagine 
that it could be useful to a lot of people if it could be set via some property 
that only files from the source directory should be considered in the 
dependency calculation.

Should one open a bug report with this? (Does the CMake bug tracking system 
have the ability to track "feature requests"?)

Cheers,
   Attila

> On 07 Dec 2015, at 11:55, Attila Krasznahorkay 
>  wrote:
> 
> Dear All,
> 
> Maybe I should've google-d better. So now I started experimenting with 
> include_regular_expression(...).
> 
> https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html
> 
> But now I'm having a problem with expressing my intent with a regular 
> expression. In principle I'd like to only take headers from the source 
> directory into account in the dependency calculation. So I first tried this:
> 
> include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" )
> 
> But this was way too restrictive. As headers from the source directory 
> normally show up with relative paths in the depend.make files.
> 
> So okay, I tried this next:
> 
> include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" )
> 
> (To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or 
> are not starting with "/".)
> 
> But this didn't work either. I'm back to having all the boost files in my 
> dependency list.
> 
> Any suggestion for how I could express my intent in a regular expression that 
> CMake would understand?
> 
> Cheers,
> Attila
> 
>> On 07 Dec 2015, at 10:57, Attila Krasznahorkay 
>>  wrote:
>> 
>> Dear All,
>> 
>> I'm struggling since a few days with the following issue.
>> 
>> Our development setup is such that we build large software projects in a 
>> nightly build system, which puts these projects onto a network drive. The 
>> developers then set up these nightly projects, and build their own code 
>> against them. (They can even rebuild parts that are in the nightly itself, 
>> that also required some clever tricks in CMake...)
>> 
>> This kind of works by now. But the system is incredibly slow. When I try to 
>> build some source code against installed releases on the network file 
>> system, >90% of the time is seemingly just spent in dependency 
>> calculation/evaluation. To demonstrate the extent of the issue, here is an 
>> example of the files generated by CMake for one of our "packages". (Sorry, 
>> they are pretty large. But that's the point...) Mind you, this is a very 
>> simple package that just picks up Boost from the network disk. For high 
>> level packages the depend.make file can be up to 2 MB in size. :-(
>> 
>> 
>> 
>> As you can see, I tried to convince CMake to treat the include directories 
>> coming from the network file system (AFS) as system include directories. But 
>> still, the dependencies put into depend.make list every single header file 
>> that the build targets have any relationship with.
>> 
>> As it turns out, AFS is pretty slow for such operations. Checking the change 
>> times of thousands of files. At

[CMake] Making CMake not use -isystem at all

2015-12-07 Thread Attila Krasznahorkay

Dear All,

I'm still debugging the performance problems of our build. But now I bumped 
into another surprising thing.

Our "highest level" packages can depend on a *lot* of low level packages. The 
one I'm testing now depends on more than 180 of them.

This generates >180 -isystem flags for the compilation lines. But I found a 
very surprising thing. If I replace all of these -isystem flags with -I ones by 
simply modifying the flags.cmake files that CMake generated for me, the build 
time of my code is cut to less than half of what it is when using -isystem.

So... How do I tell CMake to forget about using -isystem all together, and take 
all my include directories with -I?

Not using SYSTEM in target_include_directories and include_directories doesn't 
seem to make a difference. I still get all my out-of-source directories with 
-isystem. I even tried setting CMAKE_INCLUDE_SYSTEM_FLAG_CXX and 
CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I " forcefully. But this didn't help either. 
Neither did explicitly unsetting these variables.

How could it be done then? How could I force CMake to always use -I for the 
directories that I give to either include_directories or 
target_include_directories?

Cheers,
  Attila
-- 

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] MPI wrappers vs FindMPI

2015-12-07 Thread Brad King

On 12/04/2015 05:51 PM, Zaak Beekman wrote:
> What are the pros and cons of using FindMPI over passing FC=mpif90 and 
> CC=mpicc?

It shouldn't matter much if all the code in the project is meant
to be build for MPI.  Using plain FindMPI with the CC/CXX/FC set
to the system compilers is cleaner for building only a subset of
targets for MPI.  FindMPI will look for the MPI compilers separately
in order to ask them for the proper flags to tell the system compiler
how to use MPI, and then project CMake code can take responsibility
for applying that information to the desired subset of its targets.
Using CC=mpicc, FindMPI will recognize that the C compiler is already
a MPI compiler and not bother to look for a separate one to query
the settings (and similarly for C++ and Fortran).

-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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1644-g8890311

2015-12-07 Thread Chuck Atkins

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  88903117356d43bca0ae6e01b5aa3b687bc8a32f (commit)
   via  eb253f04c3b90cfd692d664fbdfe289c1d0b61a0 (commit)
   via  0763a8365528166747746e3b94e74ca98d0d705f (commit)
   via  5eaac0c96ac51e1300664ef37239f3215bb58489 (commit)
  from  270a1aef1c938e7683fb338075c6db432c50bc0e (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=88903117356d43bca0ae6e01b5aa3b687bc8a32f
commit 88903117356d43bca0ae6e01b5aa3b687bc8a32f
Merge: 270a1ae eb253f0
Author: Chuck Atkins 
AuthorDate: Mon Dec 7 11:31:26 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 11:31:26 2015 -0500

Merge topic 'detect-cray-wrappers' into next

eb253f04 Cray: Refactor the Cray platform files to use compiler wrapper 
checks
0763a836 Cray: Add macro tests to detect the Cray compiler wrappers
5eaac0c9 Compiler: Add infrastructure for detecting compiler wrappers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb253f04c3b90cfd692d664fbdfe289c1d0b61a0
commit eb253f04c3b90cfd692d664fbdfe289c1d0b61a0
Author: Chuck Atkins 
AuthorDate: Wed Dec 2 10:00:44 2015 -0600
Commit: Chuck Atkins 
CommitDate: Mon Dec 7 11:18:11 2015 -0500

Cray: Refactor the Cray platform files to use compiler wrapper checks

This is an extensive refactoring of the Cray compiler wrapper usage.
Using the new compiler wrapper checks, the CrayPrgEnv info files have
been moved from Platform/ to Compiler/.  Thhe adjusted naming convention
allows the compiler-wrapper information files to be loaded for both the
CrayLinuxEnvironment platform when cross-compiling and the Linux
platform if building natively on the Cray compute nodes.  It also
creates a seperation of common arguments for compiler id and language
information used to perfrom the appropriate introspection of implicit
arguments and libvraries used by the compiler wrappers based on the
loaded module environment.

diff --git a/Modules/Compiler/CrayPrgEnv-C.cmake 
b/Modules/Compiler/CrayPrgEnv-C.cmake
new file mode 100644
index 000..6b461ce
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-C.cmake
@@ -0,0 +1,11 @@
+if(__craylinux_crayprgenv_c)
+  return()
+endif()
+set(__craylinux_crayprgenv_c 1)
+
+include(Compiler/CrayPrgEnv)
+macro(__CrayPrgEnv_setup_C compiler_cmd link_cmd)
+  __CrayPrgEnv_setup(C
+${CMAKE_ROOT}/Modules/CMakeCCompilerABI.c
+${compiler_cmd} ${link_cmd})
+endmacro()
diff --git a/Modules/Compiler/CrayPrgEnv-CXX.cmake 
b/Modules/Compiler/CrayPrgEnv-CXX.cmake
new file mode 100644
index 000..aad85b6
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-CXX.cmake
@@ -0,0 +1,11 @@
+if(__craylinux_crayprgenv_cxx)
+  return()
+endif()
+set(__craylinux_crayprgenv_cxx 1)
+
+include(Compiler/CrayPrgEnv)
+macro(__CrayPrgEnv_setup_CXX compiler_cmd link_cmd)
+  __CrayPrgEnv_setup(CXX
+${CMAKE_ROOT}/Modules/CMakeCXXCompilerABI.cpp
+${compiler_cmd} ${link_cmd})
+endmacro()
diff --git a/Modules/Compiler/CrayPrgEnv-Cray-C.cmake 
b/Modules/Compiler/CrayPrgEnv-Cray-C.cmake
new file mode 100644
index 000..547a4b4
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-Cray-C.cmake
@@ -0,0 +1,7 @@
+if(__craylinux_crayprgenv_cray_c)
+  return()
+endif()
+set(__craylinux_crayprgenv_cray_c 1)
+
+include(Compiler/CrayPrgEnv-C)
+__CrayPrgEnv_setup_C("/opt/cray/cce/.*/ccfe" "/opt/cray/cce/.*/ld")
diff --git a/Modules/Compiler/CrayPrgEnv-Cray-CXX.cmake 
b/Modules/Compiler/CrayPrgEnv-Cray-CXX.cmake
new file mode 100644
index 000..df8452c
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-Cray-CXX.cmake
@@ -0,0 +1,7 @@
+if(__craylinux_crayprgenv_cray_cxx)
+  return()
+endif()
+set(__craylinux_crayprgenv_cray_cxx 1)
+
+include(Compiler/CrayPrgEnv-CXX)
+__CrayPrgEnv_setup_CXX("/opt/cray/cce/.*/ccfe" "/opt/cray/cce/.*/ld")
diff --git a/Modules/Compiler/CrayPrgEnv-Cray-Fortran.cmake 
b/Modules/Compiler/CrayPrgEnv-Cray-Fortran.cmake
new file mode 100644
index 000..9f46a04
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-Cray-Fortran.cmake
@@ -0,0 +1,7 @@
+if(__craylinux_crayprgenv_cray_fortran)
+  return()
+endif()
+set(__craylinux_crayprgenv_cray_fortran 1)
+
+include(Compiler/CrayPrgEnv-Fortran)
+__CrayPrgEnv_setup_Fortran("/opt/cray/cce/.*/ftnfe" "/opt/cray/cce/.*/ld")
diff --git a/Modules/Compiler/CrayPrgEnv-Fortran.cmake 
b/Modules/Compiler/CrayPrgEnv-Fortran.cmake
new file mode 100644
index 000..9c4d269
--- /dev/null
+++ b/Modules/Compiler/CrayPrgEnv-Fortran.cmake
@@ -0,0

Re: [cmake-developers] [PATCH] Add support for multiple parameters in cmake -E copy_directory command

2015-12-07 Thread Brad King

On 12/06/2015 02:40 PM, Bartosz Kosiorek wrote:
> added support for multiple source directories into copy_directory

Thanks.  Applied with minor tweaks:

 cmake: Refine -E chdir documentation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0903812b

 cmake: Refine -E copy_if_different implementation indentation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93cc80ae

 cmake: Refine -E copy[_if_different] documentation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98be140f

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

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015873]: CMake hangs indefinitely after executing other tools (e.g., gmake, getconf, file)

2015-12-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15873 
== 
Reported By:Ralf Mitschke
Assigned To:
== 
Project:CMake
Issue ID:   15873
Category:   CMake
Reproducibility:always
Severity:   block
Priority:   high
Status: new
== 
Date Submitted: 2015-12-07 04:16 EST
Last Modified:  2015-12-07 04:16 EST
== 
Summary:CMake hangs indefinitely after executing other tools
(e.g., gmake, getconf, file)
Description: 
CMake is used in a virtual machine environment and started from Jenkins for
large scale build automation of C++ based projects (so not only a single
project).

The error mostly occurs in the compiler detection phase.
The spawned gmake or getconf processes CMake calls are reported as zombie
processes in the OS.
The cmake process then hangs indefinitely in on a select statement to a UNIX
pipe it needs for inter-process communication (a stack trace is posted as
additional information).
The issue was even observed earlier in the build, where CMake was executing the
process "file", possibly to read the CMakeLists.txt or another input file.

The frequency of the occurrence varies from machine to machine.
But overall, it happens reliably in 1 of 500 runs.

I suspect it is a timing issue and outside of automation not often found.
As a workaround, I created a patched version of the file
Source/kwsys/ProcessUNIX.c

There was some code to completely remove the pipe select mechanism and revert to
polling the pipes. By switching the following definition to false we got around
the problem:
# define KWSYSPE_USE_SELECT 0

But CMake seems to get slower when not using selects.

Steps to Reproduce: 
- Create a simple C++ project
- Run a batch script to start the build 1000 times.


Additional Information: 
Stack trace where CMake hangs in pipe select statement:

https://public.kitware.com/Bug/view.php?id=0  0x7fab1410ea43 in
__select_nocancel () from /lib64/libc.so.6
https://public.kitware.com/Bug/view.php?id=1  0x007eb662 in
cmsysProcess_WaitForData ()
https://public.kitware.com/Bug/view.php?id=2  0x005c91ac in
cmSystemTools::RunSingleCommand(std::vector const&, std::string*, std::string*, int*, char
const*, cmSystemTools::OutputOption, double) ()
https://public.kitware.com/Bug/view.php?id=3  0x0053c9f3 in
cmGlobalGenerator::Build(std::string const&, std::string const&, std::string
const&, std::string const&, std::string&, std::string const&, std::string
const&, bool, bool, bool, double, cmSystemTools::OutputOption,
std::vector const&) ()
https://public.kitware.com/Bug/view.php?id=4  0x0053d093 in
cmGlobalGenerator::TryCompile(std::string const&, std::string const&,
std::string const&, std::string const&, bool, std::string&, cmMakefile*) ()
https://public.kitware.com/Bug/view.php?id=5  0x005745bc in
cmMakefile::TryCompile(std::string const&, std::string const&, std::string
const&, std::string const&, bool, std::vector const*, std::string&) ()
https://public.kitware.com/Bug/view.php?id=6  0x00676745 in
cmCoreTryCompile::TryCompileCode(std::vector const&) ()
https://public.kitware.com/Bug/view.php?id=7  0x00688453 in
cmTryCompileCommand::InitialPass(std::vector const&, cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=8  0x00584374 in
cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=9  0x006ac560 in
cmIfFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&,
cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=10 0x005841b1 in
cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=11 0x0065065f in
cmFunctionHelperCommand::InvokeInitialPass(std::vector const&, cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=12 0x005845cd in
cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=13 0x006ac560 in
cmIfFunctionBlocker::IsFunctionBlocked(cmListFileFunction const&, cmMakefile&,
cmExecutionStatus&) ()
https://public.kitware.com/Bug/view.php?id=14 0x005841b1 in
cmMakefile::ExecuteCommand(cmListFileFunction

[CMake] Control the build target's external dependencies

2015-12-07 Thread Attila Krasznahorkay

Dear All,

I'm struggling since a few days with the following issue.

Our development setup is such that we build large software projects in a 
nightly build system, which puts these projects onto a network drive. The 
developers then set up these nightly projects, and build their own code against 
them. (They can even rebuild parts that are in the nightly itself, that also 
required some clever tricks in CMake...)

This kind of works by now. But the system is incredibly slow. When I try to 
build some source code against installed releases on the network file system, 
>90% of the time is seemingly just spent in dependency calculation/evaluation. 
To demonstrate the extent of the issue, here is an example of the files 
generated by CMake for one of our "packages". (Sorry, they are pretty large. 
But that's the point...) Mind you, this is a very simple package that just 
picks up Boost from the network disk. For high level packages the depend.make 
file can be up to 2 MB in size. :-(



depend.make
Description: Binary data


flags.make
Description: Binary data


As you can see, I tried to convince CMake to treat the include directories 
coming from the network file system (AFS) as system include directories. But 
still, the dependencies put into depend.make list every single header file that 
the build targets have any relationship with.

As it turns out, AFS is pretty slow for such operations. Checking the change 
times of thousands of files. At least this is what I contribute the 
ridiculously slow build times to. (Not for this example. This package still 
builds reasonably. It's the higher level packages that break down completely. I 
just couldn't attach example files from those due to the size limitations of 
this mailing list.)

So... How could one convince CMake to exclude some directories from the 
dependency setup? The files that are part of the nightly builds should 
definitely not need to be checked for changes every time I run a build. As you 
can see, depend.make even list all the Boost headers at the moment. :-(

What I tried so far was to specify the include directories using SYSTEM in 
target_include_directories. But it didn't make any difference whether I used 
SYSTEM or not.

Is there some other mechanism that I could use here?

Cheers,
Attila-- 

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] Shared library from sources in several subdirectories

2015-12-07 Thread Nils Gladitz




On 12/04/2015 03:05 PM, Bruce Stephens wrote:

Any suggestions on how to organise that? Presumably there are
lots of examples in (for example) KDE, but I'm not familiar enough
with that codebase to be able to find them easily.

Currently our GNU Make build builds static libraries in the 
subdirectories,
then those are put into a big static library and that's linked into a 
shared

library. (The last step uses a shell script which knows how to do that for
various platforms.)

My first attempt uses add_library(... OBJECT ...) in the subdirectories,
then add_library(... SHARED $ $)
to combine them.

That works, though it means repeating the same information (more or 
less) twice

since for each add_subdirectory() there'll be a $. Also
the dependent libraries need to be added in the top-level but they're 
triggered
by the subdirectory (by the looks of it I can't use 
target_link_libraries() on an OBJECT
library). It works, though, and didn't take me very long to do, and 
the result looks

clean and relatively easy to follow.

Any better ways to do this? (In the particular case I'm looking at, 
splitting the
libraries and just having one per subdirectory might make sense, but 
not in all

cases.)


I would avoid creating these single use, per directory libraries entirely.

A single target can build sources located in any number of directories.

If you want to subdivide the source file listing of that one target for 
organizational purposes you can do so with e.g. include(), 
target_sources() and/or list variables.


Nils

--

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] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-12-07 Thread Rashad Kanavath

Hello David,

It didn't worked. I end up passing -wno-cpp to the cmake flags to finally
get over this issue.

I don't get  how CTEST_CUSTOM_WARNING_EXCEPTION works.

How does this compare the regex when it gets a warning?

How do I disable all warnings from a directory? eg:
/path/to/build/Superbuild/TIFF/build



On Fri, Nov 6, 2015 at 1:09 PM, Rashad M  wrote:

>
> So using *.#warning.*deprecated.* should work?
>
> I will test this and let you know.
>
> On Thu, Nov 5, 2015 at 4:49 PM, David Cole  wrote:
>
>> Looks to me like it might be (I'm hopeful) working at ignoring the
>> line which matches the expression ".*vcl_deprecated_header.h.*" ...
>>
>> But then, the following line is:
>>
>>  # warning "deprecated"
>>
>> Since that line does not match any of your expressions, maybe that's
>> the one triggering this warning slipping through as unignored?
>>
>>
>> HTH,
>> D
>>
>>
>>
>>
>> On Thu, Nov 5, 2015 at 10:01 AM, Rashad M 
>> wrote:
>> > yes.
>> >
>> > On Thu, Nov 5, 2015 at 1:46 PM, David Cole  wrote:
>> >>
>> >> Does your ctest -S script call ctest_read_custom_files
>> >> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html
>> after
>> >> ctest_configure?
>> >>
>> >>
>> >> On Thursday, November 5, 2015, Rashad M 
>> >> wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> I have CTestCustom.cmake.in file in source tree with the following
>> >>> contents
>> >>>
>> >>>
>> >>>
>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>> >>>
>> >>> during ctest build CTestCustom.cmake file is getting generated inside
>> the
>> >>> build tree.
>> >>>
>> >>> But however the warnings are not filtered out on the dashboard. For
>> >>> instance, see the dashboard submission
>> >>>
>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>> >>>
>> >>> and see the exception for vcl_deprecated_header
>> >>>
>> >>>
>> >>>
>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>> >>>
>> >>> The warning appears on dashobard anyway. Can someone point me in the
>> >>> right direction. ?
>> >>>
>> >>> Thanks in advance.
>> >>>
>> >>>
>> >>> CMake Version:
>> >>> 2.8.12.2
>> >>>
>> >>> CDash Version:
>> >>> 2.2.3
>> >>>
>> >>> uname -a
>> >>> Linux ubuntu
>> >>>
>> >>>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
>> >>> x86_64 x86_64 GNU/Linux
>> >>> --
>> >>> Regards,
>> >>>Rashad
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> >Rashad
>>
>
>
>
> --
> Regards,
>Rashad
>



-- 
Regards,
   Rashad
-- 

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] Control the build target's external dependencies

2015-12-07 Thread Attila Krasznahorkay

Dear All,

Maybe I should've google-d better. So now I started experimenting with 
include_regular_expression(...).

https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html

But now I'm having a problem with expressing my intent with a regular 
expression. In principle I'd like to only take headers from the source 
directory into account in the dependency calculation. So I first tried this:

include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" )

But this was way too restrictive. As headers from the source directory normally 
show up with relative paths in the depend.make files.

So okay, I tried this next:

include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" )

(To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or 
are not starting with "/".)

But this didn't work either. I'm back to having all the boost files in my 
dependency list.

Any suggestion for how I could express my intent in a regular expression that 
CMake would understand?

Cheers,
 Attila

> On 07 Dec 2015, at 10:57, Attila Krasznahorkay 
>  wrote:
> 
> Dear All,
> 
> I'm struggling since a few days with the following issue.
> 
> Our development setup is such that we build large software projects in a 
> nightly build system, which puts these projects onto a network drive. The 
> developers then set up these nightly projects, and build their own code 
> against them. (They can even rebuild parts that are in the nightly itself, 
> that also required some clever tricks in CMake...)
> 
> This kind of works by now. But the system is incredibly slow. When I try to 
> build some source code against installed releases on the network file system, 
> >90% of the time is seemingly just spent in dependency 
> calculation/evaluation. To demonstrate the extent of the issue, here is an 
> example of the files generated by CMake for one of our "packages". (Sorry, 
> they are pretty large. But that's the point...) Mind you, this is a very 
> simple package that just picks up Boost from the network disk. For high level 
> packages the depend.make file can be up to 2 MB in size. :-(
> 
> 
> 
> As you can see, I tried to convince CMake to treat the include directories 
> coming from the network file system (AFS) as system include directories. But 
> still, the dependencies put into depend.make list every single header file 
> that the build targets have any relationship with.
> 
> As it turns out, AFS is pretty slow for such operations. Checking the change 
> times of thousands of files. At least this is what I contribute the 
> ridiculously slow build times to. (Not for this example. This package still 
> builds reasonably. It's the higher level packages that break down completely. 
> I just couldn't attach example files from those due to the size limitations 
> of this mailing list.)
> 
> So... How could one convince CMake to exclude some directories from the 
> dependency setup? The files that are part of the nightly builds should 
> definitely not need to be checked for changes every time I run a build. As 
> you can see, depend.make even list all the Boost headers at the moment. :-(
> 
> What I tried so far was to specify the include directories using SYSTEM in 
> target_include_directories. But it didn't make any difference whether I used 
> SYSTEM or not.
> 
> Is there some other mechanism that I could use here?
> 
> Cheers,
>Attila

-- 

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] Problems with transitive dependencies

2015-12-07 Thread Chris Wilson

Dear CMake users,

I'm trying to use CMake to replace the complex hand-built Visual Studio
configuration of our open source project, Box Backup. And I'm having
trouble making it generate the correct transitive dependencies between
modules, particularly for include directories.

We have a lot of modules whose header files need to be part of the public
interface to link to these modules. I thought from the manual that "The
usage requirements of a target can transitively propagate to dependents"
but I can't make it work (for anything except link libraries).

Here is a toy example taken from the manual:

add_library(archive archive.cpp)
target_compile_definitions(archive PUBLIC USING_ARCHIVE_LIB)

add_library(serialization serialization.cpp)
target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB)

add_library(archiveExtras extras.cpp)
target_link_libraries(archiveExtras PUBLIC archive)
target_link_libraries(archiveExtras PRIVATE serialization)
# archiveExtras is compiled with -DUSING_ARCHIVE_LIB
# and -DUSING_SERIALIZATION_LIB

add_executable(consumer consumer.cpp)
# consumer is compiled with -DUSING_ARCHIVE_LIB
target_link_libraries(consumer archiveExtras)


My understanding is that the target_compile_definitions are part of the
public interface of the archive module, and should be added to anything
that links to it, which archiveExtras does. But if I add some debugging
messages after the above code:

foreach (lib archive serialization archiveExtras consumer)
  get_property(ill TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
  get_property(ll TARGET ${lib} PROPERTY LINK_LIBRARIES)
  get_property(icd TARGET ${lib} PROPERTY INTERFACE_COMPILE_DEFINITIONS)
  get_property(cd TARGET ${lib} PROPERTY COMPILE_DEFINITIONS)
  message(STATUS "${lib}: INTERFACE_LINK_LIBRARIES = \"${ill}\" "
"LINK_LIBRARIES = \"${ll}\"")
  message(STATUS "${lib}: INTERFACE_COMPILE_DEFINITIONS = \"${icd}\" "
"COMPILE_DEFINITIONS = \"${cd}\"")
endforeach()


I can see that archiveExtras inherits the link libraries of archive, *but
not its compile_definitions* (nor the include directories if I try to
inherit them instead):

-- archive: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- archive: INTERFACE_COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB"
COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB"

-- serialization: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = ""
-- serialization: INTERFACE_COMPILE_DEFINITIONS = "USING_SERIALIZATION_LIB"
COMPILE_DEFINITIONS = ""

-- archiveExtras: INTERFACE_LINK_LIBRARIES =
"archive;$" LINK_LIBRARIES =
"archive;serialization"
-- archiveExtras: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS =
""

-- consumer: INTERFACE_LINK_LIBRARIES = "archiveExtras" LINK_LIBRARIES =
"archiveExtras"
-- consumer: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = ""


The COMPILE_DEFINITIONS of archiveExtras is empty; it has not inherited
anything.

The manual says:

Because archive is a PUBLIC dependency of archiveExtras, the usage
> requirements of it are propagated to consumer too. Because serialization is
> a PRIVATE dependency of archive, the usage requirements of it are not
> propagated to consumer...
>


"Usage requirements are propagated by reading the INTERFACE_ variants of
> target properties from dependencies and appending the values to the
> non-INTERFACE_ variants of the operand. For example, the
> INTERFACE_INCLUDE_DIRECTORIES of dependencies is read and appended to the
> INCLUDE_DIRECTORIES of the operand."


I would assume that the same happens for COMPILE_DEFINITIONS: it should be
copied from the INTERFACE_COMPILE_DEFINITIONS of the dependencies. But this
doesn't appear to be happening, as far as I can tell. Nor is the "consumer
compiled with -DUSING_ARCHIVE_LIB", contrary to the comment (at least it's
not in the COMPILE_DEFINITIONS).

Can anyone tell me what I'm doing wrong? Specifiying "dependencies" the
wrong way? I would really appreciate some help :) Do I have to hard-code or
script all the transitive dependencies myself, or is there something I'm
missing?

Thanks in advance, Chris.
-- 

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] Set tests to "not-run" in CDash

2015-12-07 Thread Derek Dresser

Hello,
We sometimes have tests that are failing and want to disable them
temporarily, but still be reminded of them in the CDash dashboard.  To
accomplish this, we sometimes map the test name to a non existing
executable.  CTest then can't find the executable and marks the test as
"not run" in CDash.

That way we see that there is a test in the "not run" column and it reminds
us that we have a test that needs some work before it can be re-enabled.

Is there a better way to intentionally mark a test as "not run?"  We still
want to see it in the "not run" column.

Thanks,
Derek
-- 

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] Making CMake not use -isystem at all

2015-12-07 Thread Alexander Neundorf

On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote:
> Dear All,
> 
> I'm still debugging the performance problems of our build. But now I 
bumped
> into another surprising thing.
> 
> Our "highest level" packages can depend on a *lot* of low level 
packages.
> The one I'm testing now depends on more than 180 of them.
> 
> This generates >180 -isystem flags for the compilation lines. But I 
found a
> very surprising thing. If I replace all of these -isystem flags with -I
> ones by simply modifying the flags.cmake files that CMake generated 
for me,
> the build time of my code is cut to less than half of what it is when 
using
> -isystem.
> 
> So... How do I tell CMake to forget about using -isystem all together, 
and
> take all my include directories with -I?
> 
> Not using SYSTEM in target_include_directories and 
include_directories
> doesn't seem to make a difference. I still get all my out-of-source
> directories with -isystem. I even tried setting
> CMAKE_INCLUDE_SYSTEM_FLAG_CXX and 
CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I "
> forcefully. But this didn't help either. Neither did explicitly unsetting
> these variables.

I would have expected this to work.
Maybe set them to -I on the initial cmake run ?

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

Re: [CMake] Making CMake not use -isystem at all

2015-12-07 Thread Attila Krasznahorkay

Hi Alex,

From what I could see, if the base CMake code decides that internally 
CMAKE_INCLUDE_SYSTEM_FLAG_CXX needs to be set to “-isystem “, then I can’t 
influence this decision from the outside.

But the reason that the decision between using -I and -isystem seemed so 
inexplainable to me was that my project uses imported targets quite heavily. 
And as I had to learn, CMake treats the include directories set on imported 
libraries as system includes by default. Regardless whether those were set as 
system includes originally or not. After some google-ing I found out about it 
here:

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

After setting CMAKE_NO_SYSTEM_FROM_IMPORTED to TRUE, my project now uses -I and 
-isystem includes as I originally expected it to.

And it could still be interesting to people that apparently using -isystem for 
directories on network disks is not a good idea. I’m really not sure what GCC 
does in the background exactly, but it clearly has some noticeable overhead 
over using -I for the same directories. So for now I just stopped using system 
include directories myself completely.

Cheers,
Attila

> On Dec 7, 2015, at 10:05 PM, Alexander Neundorf  
> wrote:
> 
> On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote:
> > Dear All,
> > 
> > I'm still debugging the performance problems of our build. But now I bumped
> > into another surprising thing.
> > 
> > Our "highest level" packages can depend on a *lot* of low level packages.
> > The one I'm testing now depends on more than 180 of them.
> > 
> > This generates >180 -isystem flags for the compilation lines. But I found a
> > very surprising thing. If I replace all of these -isystem flags with -I
> > ones by simply modifying the flags.cmake files that CMake generated for me,
> > the build time of my code is cut to less than half of what it is when using
> > -isystem.
> > 
> > So... How do I tell CMake to forget about using -isystem all together, and
> > take all my include directories with -I?
> > 
> > Not using SYSTEM in target_include_directories and include_directories
> > doesn't seem to make a difference. I still get all my out-of-source
> > directories with -isystem. I even tried setting
> > CMAKE_INCLUDE_SYSTEM_FLAG_CXX and CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I "
> > forcefully. But this didn't help either. Neither did explicitly unsetting
> > these variables.
>  
> I would have expected this to work.
> Maybe set them to -I on the initial cmake run ?
>  
> 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

[CMake] CMake and a simple java example

2015-12-07 Thread Kristian

Dear All,

I am learning CMake, and one of my personal lessons is combine Java
and CMake. I made a small example (HelloWorld.java):

==

public class HelloWorld
{
   public static void main(String[] args)
   {
  System.out.println("Hey :)");
   }
}

==

And a CMakeLists.txt file:

==

cmake_minimum_required(VERSION 2.8)
project(HelloWorld)

find_package(Java REQUIRED)
include(UseJava)

set(JAR_NAME HelloWorld)
set(JAVA_SOURCE_DIRECTORY )
set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java)
add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})

==

Then I go into that directory where the CMakeLists.txt is and start the command

==
cmake --target=HelloWorld --build .
==

Output is:

==

-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Java: /usr/bin/java (found version "1.8.0.66")
-- Jar file /home/some/Downloads/HelloWorld/HelloWorld.jar
-- Class compiled to /home/some/Downloads/HelloWorld/CMakeFiles/HelloWorld.dir
-- Configuring done
-- Generating done
-- Build files have been written to: /home/some/Downloads/HelloWorld

==

But when I start the command "make", then I get the following output:

==

Scanning dependencies of target HelloWorld
make[2]: *** No rule to make target `/HelloWorld.java', needed by
`CMakeFiles/HelloWorld.dir/java_compiled_HelloWorld'.  Stop.
make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2
make: *** [all] Error 2

==

Can you tell me, what I am doing wrong?
-- 

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] Copying directories as post build events without losing parent directory

2015-12-07 Thread David Cole via CMake

$ cmake -E copy_directory foo bar/foo

?


On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey  wrote:
> I have a custom target which runs a command similar to this:
>
> $ cmake -E copy_directory foo bar
>
> The problem is that the contents of "foo" are copied inside of "bar",
> instead of it creating a directory "bar/foo" and putting the contents
> in there.
>
> Is there a way to make copy_directory behave like this? If not, I
> guess my only option is to create a little CMake script that runs
> file(INSTALL) to copy the directories like I want.
> --
>
> 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] Copying directories as post build events without losing parent directory

2015-12-07 Thread Robert Dailey

On Mon, Dec 7, 2015 at 3:59 PM, David Cole  wrote:
> $ cmake -E copy_directory foo bar/foo
>
> ?
>
>
> On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey  
> wrote:
>> I have a custom target which runs a command similar to this:
>>
>> $ cmake -E copy_directory foo bar
>>
>> The problem is that the contents of "foo" are copied inside of "bar",
>> instead of it creating a directory "bar/foo" and putting the contents
>> in there.
>>
>> Is there a way to make copy_directory behave like this? If not, I
>> guess my only option is to create a little CMake script that runs
>> file(INSTALL) to copy the directories like I want.
>> --
>>
>> 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

That's the obvious answer but due to complexity reasons I don't want
to repeat the destination directory name. I want the copy to be
inclusive of the source directory name. I'd have to use
get_filename_component() to find the leaf directory name in the list
of directories I provide to my function for copying, simply to repeat
that name in the destination path I build. I want to avoid this.
Another weirdness is that I like to pass in a list with a mixture of
directories and files. Think of this is a way for me to pass in a list
of game data resources that need to be copied to the EXE directory so
the game can find them and run. I also have to add weird
if(IS_DIRECTORY) checks so I can tell my custom command to use "copy"
or "copy_directory".

A simple little install.cmake script that I run is able to do this,
but as far as complexity goes, it doesn't save me a whole lot:

function( copy_data )
if( NOT TARGET copy_data )
add_custom_target( copy_data COMMENT "Copying data directories
and files..." )
endif()

set( data_directories ${ARGN} )

foreach( data ${data_directories} )
get_filename_component( data ${data} ABSOLUTE )
set( output_dir "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$" )
set( install_script "${BUILD_CMAKE_DIR}/scripts/install.cmake" )

add_custom_command( TARGET copy_data POST_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS "-DSOURCE=${data}" "-DOUTPUT_DIR=${output_dir}" -P
"${install_script}"
)
endforeach()
endfunction()
-- 

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] Copying directories as post build events without losing parent directory

2015-12-07 Thread Robert Dailey

On Mon, Dec 7, 2015 at 4:15 PM, Robert Dailey  wrote:
> On Mon, Dec 7, 2015 at 3:59 PM, David Cole  wrote:
>> $ cmake -E copy_directory foo bar/foo
>>
>> ?
>>
>>
>> On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey  
>> wrote:
>>> I have a custom target which runs a command similar to this:
>>>
>>> $ cmake -E copy_directory foo bar
>>>
>>> The problem is that the contents of "foo" are copied inside of "bar",
>>> instead of it creating a directory "bar/foo" and putting the contents
>>> in there.
>>>
>>> Is there a way to make copy_directory behave like this? If not, I
>>> guess my only option is to create a little CMake script that runs
>>> file(INSTALL) to copy the directories like I want.
>>> --
>>>
>>> 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
>
> That's the obvious answer but due to complexity reasons I don't want
> to repeat the destination directory name. I want the copy to be
> inclusive of the source directory name. I'd have to use
> get_filename_component() to find the leaf directory name in the list
> of directories I provide to my function for copying, simply to repeat
> that name in the destination path I build. I want to avoid this.
> Another weirdness is that I like to pass in a list with a mixture of
> directories and files. Think of this is a way for me to pass in a list
> of game data resources that need to be copied to the EXE directory so
> the game can find them and run. I also have to add weird
> if(IS_DIRECTORY) checks so I can tell my custom command to use "copy"
> or "copy_directory".
>
> A simple little install.cmake script that I run is able to do this,
> but as far as complexity goes, it doesn't save me a whole lot:
>
> function( copy_data )
> if( NOT TARGET copy_data )
> add_custom_target( copy_data COMMENT "Copying data directories
> and files..." )
> endif()
>
> set( data_directories ${ARGN} )
>
> foreach( data ${data_directories} )
> get_filename_component( data ${data} ABSOLUTE )
> set( output_dir "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$" )
> set( install_script "${BUILD_CMAKE_DIR}/scripts/install.cmake" )
>
> add_custom_command( TARGET copy_data POST_BUILD
> COMMAND ${CMAKE_COMMAND}
> ARGS "-DSOURCE=${data}" "-DOUTPUT_DIR=${output_dir}" -P
> "${install_script}"
> )
> endforeach()
> endfunction()

Oh and the contents of install.cmake:

file( INSTALL ${SOURCE} DESTINATION ${OUTPUT_DIR} )
-- 

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] Shared library from sources in several subdirectories

2015-12-07 Thread Bruce Stephens

On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz  wrote:

> I would avoid creating these single use, per directory libraries entirely.
>
>
Well, creating the static libraries is obviously just an artifact of our
current
build scheme, so it makes sense to ditch it.

Creating these CMake object libraries doesn't seem bad; is there some
reason to avoid doing that? A reason for doing it is it gives targets for
target_include_directories, so just the crypto objects can be built with
the OpenSSL include directory.

Also for some reason setting the POSITION_INDEPENDENT_CODE
property for the top-level shared library (the default anyway) doesn't
seem to propagate down (and maybe it can't), and the named thing
makes it easy to apply the property to the sources. Though now I look,
I could use set_property on the sources (or the directory), and I could
use set_property similarly to add include directories (and compile
definitions).

> A single target can build sources located in any number of directories.
>
> If you want to subdivide the source file listing of that one target for
> organizational purposes you can do so with e.g. include(), target_sources()
> and/or list variables.
>

Thanks for suggesting that. For some reason it hadn't occurred to me.
I'm not sure whether that would work out better for this particular case
or not, or for the larger library I'd like to do (with ~500 sources in a
tree
of ~40 directories).

(I suspect there's not that much in it ultimately and worrying about the
choice is as much bike shedding as anything.)
-- 

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-1647-g8b8a03f

2015-12-07 Thread Domen Vrankar

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

The branch, next has been updated
   via  8b8a03fc4a03845c797523d918fc06d408dde2c7 (commit)
   via  27e6f74f29084fbdee35eb5a8d309d99d39e66d8 (commit)
   via  c926efa1398aa2c4ff273dee173d84d0031bcdf6 (commit)
  from  88903117356d43bca0ae6e01b5aa3b687bc8a32f (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=8b8a03fc4a03845c797523d918fc06d408dde2c7
commit 8b8a03fc4a03845c797523d918fc06d408dde2c7
Merge: 8890311 27e6f74
Author: Domen Vrankar 
AuthorDate: Mon Dec 7 14:22:12 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 7 14:22:12 2015 -0500

Merge topic 'cpack-rpm-percomponent-group-and-name' into next

27e6f74f CPack: Added tests for package name and group controll fields
c926efa1 CPackRPM: Configure RPM package group and name per component


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27e6f74f29084fbdee35eb5a8d309d99d39e66d8
commit 27e6f74f29084fbdee35eb5a8d309d99d39e66d8
Author: Domen Vrankar 
AuthorDate: Mon Dec 7 20:13:09 2015 +0100
Commit: Domen Vrankar 
CommitDate: Mon Dec 7 20:15:49 2015 +0100

CPack: Added tests for package name and group controll fields

diff --git a/Help/release/dev/cpack-rpm-percomponent-group-and-name.rst 
b/Help/release/dev/cpack-rpm-percomponent-group-and-name.rst
new file mode 100644
index 000..146f8ac
--- /dev/null
+++ b/Help/release/dev/cpack-rpm-percomponent-group-and-name.rst
@@ -0,0 +1,7 @@
+cpack-rpm-percomponent-group-and-name
+-
+
+* The :module:`CPackRPM` module learned to set Name and Group
+  control fields per-component.
+  See :variable:`CPACK_RPM__PACKAGE_NAME`
+  and :variable:`CPACK_RPM__PACKAGE_GROUP`.
diff --git a/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-ExpectedFiles.cmake 
b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-ExpectedFiles.cmake
new file mode 100644
index 000..1f6c11b
--- /dev/null
+++ b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-ExpectedFiles.cmake
@@ -0,0 +1,9 @@
+set(whitespaces_ "[\t\n\r ]*")
+
+set(EXPECTED_FILES_COUNT "3")
+set(EXPECTED_FILE_1 "per_component*-pkg_1.deb")
+set(EXPECTED_FILE_CONTENT_1 
"^.*/usr/foo${whitespaces_}.*/usr/foo/CMakeLists.txt$")
+set(EXPECTED_FILE_2 "per_component*-pkg_2.deb")
+set(EXPECTED_FILE_CONTENT_2 
"^.*/usr/foo${whitespaces_}.*/usr/foo/CMakeLists.txt$")
+set(EXPECTED_FILE_3 "per_component*-pkg_3.deb")
+set(EXPECTED_FILE_CONTENT_3 
"^.*/usr/foo${whitespaces_}.*/usr/foo/CMakeLists.txt$")
diff --git a/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-VerifyResult.cmake 
b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-VerifyResult.cmake
new file mode 100644
index 000..55293be
--- /dev/null
+++ b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-VerifyResult.cmake
@@ -0,0 +1,18 @@
+function(checkPackageInfo_ TYPE FILE REGEX)
+  set(whitespaces_ "[\t\n\r ]*")
+
+  getPackageInfo("${FILE}" "FILE_INFO_")
+  if(NOT FILE_INFO_ MATCHES "${REGEX}")
+message(FATAL_ERROR "Unexpected ${TYPE} in '${FILE}'; file info: 
'${FILE_INFO_}'")
+  endif()
+endfunction()
+
+# check package name
+checkPackageInfo_("name" "${FOUND_FILE_1}" 
".*Package${whitespaces_}:${whitespaces_}per_component-pkg_1")
+checkPackageInfo_("name" "${FOUND_FILE_2}" 
".*Package${whitespaces_}:${whitespaces_}second")
+checkPackageInfo_("name" "${FOUND_FILE_3}" 
".*Package${whitespaces_}:${whitespaces_}per_component-pkg_3")
+
+# check package group
+checkPackageInfo_("group" "${FOUND_FILE_1}" 
".*Section${whitespaces_}:${whitespaces_}default")
+checkPackageInfo_("group" "${FOUND_FILE_2}" 
".*Section${whitespaces_}:${whitespaces_}second_group")
+checkPackageInfo_("group" "${FOUND_FILE_3}" 
".*Section${whitespaces_}:${whitespaces_}default")
diff --git a/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-specifics.cmake 
b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-specifics.cmake
new file mode 100644
index 000..a1da1a3
--- /dev/null
+++ b/Tests/RunCMake/CPack/DEB/PER_COMPONENT_FIELDS-specifics.cmake
@@ -0,0 +1,6 @@
+set(CPACK_PACKAGE_CONTACT "someone")
+set(CPACK_DEB_COMPONENT_INSTALL "ON")
+
+set(CPACK_DEBIAN_PACKAGE_SECTION "default")
+set(CPACK_DEBIAN_PKG_2_PACKAGE_NAME "second")
+set(CPACK_DEBIAN_PKG_2_PACKAGE_SECTION "second_group")
diff --git a/Tests/RunCMake/CPack/PER_COMPONENT_FIELDS.cmake 
b/Tests/RunCMake/CPack/PER_COMPONENT_FIELDS.cmake
new file mode 100644
index 000..bb42cf4
--- /dev/null
+++ b/Tests/RunCMake/CPack/PER_COMPONENT_FIELDS.cmake
@@ -0,0 +1,5 @@
+install(FILES CMakeLists.txt DESTINATION foo COMPONENT pkg_1)

Re: [cmake-developers] [CPackRPM] Configure RPM package group and name per component

2015-12-07 Thread Domen Vrankar

2015-11-17 9:18 GMT+01:00 Domen Vrankar :
> 2015-11-15 20:32 GMT+01:00 Markus Rickert :
>> Hi,
>>
>> similar to the previous patch for CPackDeb, the attached patch adds
>> component-specific settings for group and name of an RPM package.
>>
>> CPACK_RPM__PACKAGE_GROUP allows setting the group of the
>> component with the main libraries to "Development/Libraries", while
>> "Documentation" can be used for the component with the actual documentation.
>>
>> CPACK_RPM__PACKAGE_NAME can set the package name (not the
>> filename) of a component, e.g., "foo" for libraries (instead of
>> "foo-libraries") and "foo-devel" for headers.
>
> I'll try to review it today.

Sorry for this delay...

Applied patch with minor change:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=c926efa

Thanks,
Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Add command line options for deprecation message control

2015-12-07 Thread Michael Scott


I noticed one glitch.  I built against Qt 5.5.1 on Linux and the
option dialog seems to truncate the labels.
I think I've fixed it, by using vertical layouts rather than form 
layouts and setting the size policy to expanding for the widgets, if 
that doesn't fix I'll need to look into QT in more depth as I've not got 
much experience with it. Which Linux distro did you notice it in, looks 
like gnome3?


Patches for the fix are attached.

Cheers,
Michael
>From 320d791eb6f97e590716c555da0345de31e65cfc Mon Sep 17 00:00:00 2001
From: Michael Scott 
Date: Sun, 6 Dec 2015 12:33:13 +
Subject: [PATCH 1/2] Warning messages options in cmake-gui

Created a new dialog window for the cmake-gui, which provides
controls for setting the state of suppression of developer and
deprecated warning messages. This replaces the previous single
checkbox for setting the state of suppression of developer warnings.

Added a note for the new functionality to the release notes.
---
 Help/release/dev/cmake-W-options.rst  |   3 +
 Source/QtDialog/CMakeLists.txt|   4 +
 Source/QtDialog/CMakeSetupDialog.cxx  |  15 ++--
 Source/QtDialog/CMakeSetupDialog.h|   3 +-
 Source/QtDialog/QCMake.cxx|  18 -
 Source/QtDialog/QCMake.h  |   7 +-
 Source/QtDialog/WarningMessagesDialog.cxx |  43 +++
 Source/QtDialog/WarningMessagesDialog.h   |  53 +
 Source/QtDialog/WarningMessagesDialog.ui  | 120 ++
 Source/cmake.cxx  |  33 +++-
 Source/cmake.h|   7 ++
 11 files changed, 292 insertions(+), 14 deletions(-)
 create mode 100644 Source/QtDialog/WarningMessagesDialog.cxx
 create mode 100644 Source/QtDialog/WarningMessagesDialog.h
 create mode 100644 Source/QtDialog/WarningMessagesDialog.ui

diff --git a/Help/release/dev/cmake-W-options.rst b/Help/release/dev/cmake-W-options.rst
index 57d375f..38e71f9 100644
--- a/Help/release/dev/cmake-W-options.rst
+++ b/Help/release/dev/cmake-W-options.rst
@@ -10,3 +10,6 @@ cmake-W-options
 * Warnings about deprecated functionality are now enabled by default.
   They may be suppressed with ``-Wno-deprecated`` or by setting the
   :variable:`CMAKE_WARN_DEPRECATED` variable to false.
+
+* Warnings about deprecated functionality can now be controlled in the
+  :manual:`cmake-gui(1)` application.
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index cad11f5..9161ad3 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -115,6 +115,8 @@ set(SRCS
   QCMakeWidgets.h
   RegexExplorer.cxx
   RegexExplorer.h
+  WarningMessagesDialog.cxx
+  WarningMessagesDialog.h
   )
 QT4_WRAP_UI(UI_SRCS
   CMakeSetupDialog.ui
@@ -122,6 +124,7 @@ QT4_WRAP_UI(UI_SRCS
   CrossCompiler.ui
   AddCacheEntry.ui
   RegexExplorer.ui
+  WarningMessagesDialog.ui
   )
 QT4_WRAP_CPP(MOC_SRCS
   AddCacheEntry.h
@@ -132,6 +135,7 @@ QT4_WRAP_CPP(MOC_SRCS
   QCMakeCacheView.h
   QCMakeWidgets.h
   RegexExplorer.h
+  WarningMessagesDialog.h
   )
 QT4_ADD_RESOURCES(RC_SRCS CMakeSetup.qrc)
 
diff --git a/Source/QtDialog/CMakeSetupDialog.cxx b/Source/QtDialog/CMakeSetupDialog.cxx
index 2b12834..2fc4faf 100644
--- a/Source/QtDialog/CMakeSetupDialog.cxx
+++ b/Source/QtDialog/CMakeSetupDialog.cxx
@@ -34,6 +34,7 @@
 #include "AddCacheEntry.h"
 #include "FirstConfigure.h"
 #include "RegexExplorer.h"
+#include "WarningMessagesDialog.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
 
@@ -145,9 +146,8 @@ CMakeSetupDialog::CMakeSetupDialog()
this, SLOT(doOutputErrorNext()));  // in Eclipse
 
   QMenu* OptionsMenu = this->menuBar()->addMenu(tr(""));
-  this->SuppressDevWarningsAction =
-OptionsMenu->addAction(tr(" dev Warnings (-Wno-dev)"));
-  this->SuppressDevWarningsAction->setCheckable(true);
+  OptionsMenu->addAction(tr("Warning Messages..."),
+ this, SLOT(doWarningMessagesDialog()));
   this->WarnUninitializedAction =
 OptionsMenu->addAction(tr(" Uninitialized (--warn-uninitialized)"));
   this->WarnUninitializedAction->setCheckable(true);
@@ -278,9 +278,6 @@ void CMakeSetupDialog::initialize()
   QObject::connect(this->AddEntry, SIGNAL(clicked(bool)),
this, SLOT(addCacheEntry()));
 
-  QObject::connect(this->SuppressDevWarningsAction, SIGNAL(triggered(bool)),
-   this->CMakeThread->cmakeInstance(), SLOT(setSuppressDevWarnings(bool)));
-
   QObject::connect(this->WarnUninitializedAction, SIGNAL(triggered(bool)),
this->CMakeThread->cmakeInstance(),
SLOT(setWarnUninitializedMode(bool)));
@@ -1369,3 +1366,9 @@ void CMakeSetupDialog::doOutputErrorNext()
 this->Output->setTextCursor(textCursor);
 }
 }
+
+void CMakeSetupDialog::doWarningMessagesDialog()
+{
+  WarningMessagesDialog dialog(this, this->CMakeThread->cmakeInstance());
+  dialog.exec();
+}
diff --git

[CMake] CMake not finding boost headers

2015-12-07 Thread Zac Bergquist

I'm stuck on what seems like a rather simple problem.

I've got this in my CMakeLists.txt

set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0)
set(Boost_DEBUG 1)
find_package(Boost 1.59.0 EXACT REQUIRED)

The boost_1_59_0 I'm pointing it to contains the Boost source straight from
the 1.59.0 release.

I've tried both CMake 3.3.1 and 3.4.1.  When I run CMake, I get the "Unable
to find the Boost header files" error.  Here's some of the debug output:

-- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59
-- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE
-- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS =
-- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME =
-- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS =
-- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS =
-- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables:
-- [ FindBoost.cmake:615 ]   BOOST_ROOT =
-- [ FindBoost.cmake:617 ]   BOOST_INCLUDEDIR =
/home/user/thirdparty/boost_1_59_0
-- [ FindBoost.cmake:619 ]   BOOST_LIBRARYDIR =
-- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59
-- [ FindBoost.cmake:690 ] Include debugging info:
-- [ FindBoost.cmake:692 ]   _boost_INCLUDE_SEARCH_DIRS =
/home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include
-- [ FindBoost.cmake:694 ]   _boost_PATH_SUFFIXES =
boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59

So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint.  I
looked at the source for the FindBoost module, and it comes down to:

find_path(NAMES boost/config.hpp ...).

The file exists exactly where CMake says it's looking.

$ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp
-r--r--r-- 1 user user 2188 Nov 30 16:20
/home/user/thirdparty/boost_1_59_0/boost/config.hpp

Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND.

I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I
saw that portion of the path in the suffixes, but it doesn't help).  The
only way I am able to get CMake to locate the boost headers is to install
them into a global location like /usr/local/include (which I'd like to
avoid).
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake not finding boost headers

2015-12-07 Thread Zac Bergquist

It turns out I missed some important information.  I am cross compiling,
and my toolchain file sets CMAKE_FIND_ROOT_PATH_MODE_INCLUDE to ONLY. If I
change ONLY to BOTH, CMake succesfully locates the Boost headers.

I'm not sure if this is the correct solution though.  Why would setting
this to ONLY prevent CMake from searching outside CMAKE_FIND_ROOT_PATH?

On Mon, Dec 7, 2015 at 1:44 PM, Zac Bergquist 
wrote:

> I'm stuck on what seems like a rather simple problem.
>
> I've got this in my CMakeLists.txt
>
> set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0)
> set(Boost_DEBUG 1)
> find_package(Boost 1.59.0 EXACT REQUIRED)
>
> The boost_1_59_0 I'm pointing it to contains the Boost source straight
> from the 1.59.0 release.
>
> I've tried both CMake 3.3.1 and 3.4.1.  When I run CMake, I get the
> "Unable to find the Boost header files" error.  Here's some of the debug
> output:
>
> -- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59
> -- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE
> -- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS =
> -- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME =
> -- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS =
> -- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS =
> -- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables:
> -- [ FindBoost.cmake:615 ]   BOOST_ROOT =
> -- [ FindBoost.cmake:617 ]   BOOST_INCLUDEDIR =
> /home/user/thirdparty/boost_1_59_0
> -- [ FindBoost.cmake:619 ]   BOOST_LIBRARYDIR =
> -- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59
> -- [ FindBoost.cmake:690 ] Include debugging info:
> -- [ FindBoost.cmake:692 ]   _boost_INCLUDE_SEARCH_DIRS =
> /home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include
> -- [ FindBoost.cmake:694 ]   _boost_PATH_SUFFIXES =
> boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59
>
> So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint.  I
> looked at the source for the FindBoost module, and it comes down to:
>
> find_path(NAMES boost/config.hpp ...).
>
> The file exists exactly where CMake says it's looking.
>
> $ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp
> -r--r--r-- 1 user user 2188 Nov 30 16:20
> /home/user/thirdparty/boost_1_59_0/boost/config.hpp
>
> Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND.
>
> I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I
> saw that portion of the path in the suffixes, but it doesn't help).  The
> only way I am able to get CMake to locate the boost headers is to install
> them into a global location like /usr/local/include (which I'd like to
> avoid).
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake not finding boost headers

2015-12-07 Thread Parag Chandra

The reason is that ONLY really does mean: “only look in the 
CMAKE_FIND_ROOT_PATH, and don’t look anywhere else”. This can be useful when 
cross-compiling, as it ensures that you can strictly control the location(s) 
where system headers are found, and not accidentally find them on the host 
system. It would be bad if, e.g., you were trying to target an embedded device 
and CMake and/or the compiler used the system headers from your host Linux 
machine.

Having said that, I disabled the ONLY option when I cross-compile for iOS and 
Android, as I found it too limiting. I have cross-compiled dependencies 
(including Boost) in locations outside of the CMAKE_FIND_ROOT_PATH, and I 
didn’t want to relocate them all inside CMAKE_FIND_ROOT_PATH to satisfy the 
ONLY option.


Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410

[https://www.ionicsecurity.com/IonicSigHz.png]

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309











From: CMake > on behalf 
of Zac Bergquist >
Date: Monday, December 7, 2015 at 1:56 PM
To: Cmake Mailing List >
Subject: Re: [CMake] CMake not finding boost headers

It turns out I missed some important information.  I am cross compiling, and my 
toolchain file sets CMAKE_FIND_ROOT_PATH_MODE_INCLUDE to ONLY. If I change ONLY 
to BOTH, CMake succesfully locates the Boost headers.

I'm not sure if this is the correct solution though.  Why would setting this to 
ONLY prevent CMake from searching outside CMAKE_FIND_ROOT_PATH?

On Mon, Dec 7, 2015 at 1:44 PM, Zac Bergquist 
> wrote:
I'm stuck on what seems like a rather simple problem.

I've got this in my CMakeLists.txt

set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0)
set(Boost_DEBUG 1)
find_package(Boost 1.59.0 EXACT REQUIRED)

The boost_1_59_0 I'm pointing it to contains the Boost source straight from the 
1.59.0 release.

I've tried both CMake 3.3.1 and 3.4.1.  When I run CMake, I get the "Unable to 
find the Boost header files" error.  Here's some of the debug output:

-- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59
-- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE
-- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS =
-- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME =
-- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS =
-- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS =
-- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables:
-- [ FindBoost.cmake:615 ]   BOOST_ROOT =
-- [ FindBoost.cmake:617 ]   BOOST_INCLUDEDIR = 
/home/user/thirdparty/boost_1_59_0
-- [ FindBoost.cmake:619 ]   BOOST_LIBRARYDIR =
-- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59
-- [ FindBoost.cmake:690 ] Include debugging info:
-- [ FindBoost.cmake:692 ]   _boost_INCLUDE_SEARCH_DIRS = 
/home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include
-- [ FindBoost.cmake:694 ]   _boost_PATH_SUFFIXES = 
boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59

So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint.  I 
looked at the source for the FindBoost module, and it comes down to:

find_path(NAMES boost/config.hpp ...).

The file exists exactly where CMake says it's looking.

$ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp
-r--r--r-- 1 user user 2188 Nov 30 16:20 
/home/user/thirdparty/boost_1_59_0/boost/config.hpp

Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND.

I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I saw 
that portion of the path in the suffixes, but it doesn't help).  The only way I 
am able to get CMake to locate the boost headers is to install them into a 
global location like /usr/local/include (which I'd like to avoid).


-- 

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] Static Bootstrap: CCMake & GPM

2015-12-07 Thread Huebl, Axel

Hi,

I did build a static version of CMake today successfully via

LDFLAGS="-static-libstdc++ -static-libgcc -static" \
  CFLAGS="-fPIC" \
  CXXFLAGS="-fPIC" \
  ./bootstrap

make -j
make install

(the -fPIC could also be superfluous, I just realized later that I need
to build my gcc via -fPIC, too.)

My problem: I found that in the last step of linking ccmake against a
static (pre-compiled, ubuntu 12.04) ncurses library leads to linker
errors such as:

/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`_nc_mouse_event':
(.text+0x61e): undefined reference to `Gpm_GetEvent'
/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`enable_gpm_mouse':
(.text+0x78c): undefined reference to `Gpm_Close'
/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`enable_gpm_mouse':
(.text+0x7ce): undefined reference to `Gpm_Open'
/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`enable_gpm_mouse':
(.text+0x7df): undefined reference to `Gpm_Close'
/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`initialize_mousetype':
(.text+0x935): undefined reference to `gpm_fd'
/usr/lib/x86_64-linux-gnu/libncurses.a(lib_mouse.o): In function
`mouse_activate':
(.text+0xb67): undefined reference to `gpm_fd'


I then used the make VERBOSE=1 output to simply add the static libgmp.a
via -lgpm in the end of the line to finish the install.

Is it possible that the GPM dependency is missing in the ccmake install
scripts? I tried to find the lines in

https://github.com/Kitware/CMake/blob/master/Source/CursesDialog/CMakeLists.txt

but could not find a place to add it.


Cheers,
Axel
-- 

Axel Huebl
Phone +49 351 260 3582
https://www.hzdr.de/crp
Computational Radiation Physics
Laser Particle Acceleration Division
Helmholtz-Zentrum Dresden - Rossendorf e.V.

Bautzner Landstrasse 400, 01328 Dresden
POB 510119, D-01314 Dresden
Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
  Prof. Dr.Dr.h.c. P. Joehnk
VR 1693 beim Amtsgericht Dresden



smime.p7s
Description: S/MIME Cryptographic Signature
-- 

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-652-gc6eacfd

2015-12-07 Thread 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  c6eacfd56a9c5a8da2304c446230127b6ce42470 (commit)
  from  128d569af02d95e455b5ee1d8dddec07251b7033 (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=c6eacfd56a9c5a8da2304c446230127b6ce42470
commit c6eacfd56a9c5a8da2304c446230127b6ce42470
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Dec 8 00:01:07 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Dec 8 00:01:07 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 21c4ab4..11d90d7 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 20151207)
+set(CMake_VERSION_PATCH 20151208)
 #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

40 matches

Mail list logo