[CMake] Performance issues on very large project

2016-04-05 Thread Steven Stallion
All,

I am currently working on a very large project that contains over 500
(yes, really) listfiles. A co-worker was looking into some performance
issues we were seeing during configuration and found something very
interesting. Currently configuration is taking 1m57s across several
configurations using Mac OS X as a host and the latest .dmg from
cmake.org (3.5.1).

We have a core module that provides a number of helper functions and
macros (completely stateless) that is included by most of this
listfiles (nearly 400 of them). We found that an include guard was
missing, after adding that configuration now clocks in at 1m30s.

Taking things a step further, we removed includes of the module, and
simply included it once in the top-level listfile. Configuration then
dropped to about 55s.

The results above seem to indicate a possible file I/O bottleneck.
This is very surprising to me - these builds are being run on recent
core-i7's with SSDs. Is anyone else on the list dealing with large
projects or similar configuration issues?

TIA,

Steve
-- 

Powered by www.kitware.com

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

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

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

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

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


[Cmake-commits] CMake branch, master, updated. v3.5.1-391-g8898a92

2016-04-05 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  8898a92505f887fcd2464a10a24d1ad005f24f45 (commit)
  from  73efdd46555b3236ade1f4431eb9653166b5c97f (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=8898a92505f887fcd2464a10a24d1ad005f24f45
commit 8898a92505f887fcd2464a10a24d1ad005f24f45
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Apr 6 00:01:08 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Apr 6 00:01:08 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 16960c1..fdb85ac 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 5)
-set(CMake_VERSION_PATCH 20160405)
+set(CMake_VERSION_PATCH 20160406)
 #set(CMake_VERSION_RC 1)

---

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


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


Re: [CMake] Finding all the libraries except for one located in the last path dir

2016-04-05 Thread Nils Gladitz

On 05.04.2016 23:31, Salazar De Troya, Miguel wrote:



with no line break, whereas the output variable lib_dirs:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


does have a line break and also the semicolons are removed. What’s 
happening here and how can I get rid of that?




message() concatenates its (semicolon separated) arguments.

try:
message("${lib_dirs}")

Note the quotes.

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] Finding all the libraries except for one located in the last path dir

2016-04-05 Thread Salazar De Troya, Miguel
I resolved this using the option OUTPUT_STRIP_TRAILING_WHITESPACE in 
execute_process(). 
https://cmake.org/cmake/help/v3.0/command/execute_process.html I had not seen 
it.

From: Miguel Salazar >
Date: Tuesday, April 5, 2016 at 2:31 PM
To: Miguel Salazar >, 
"cmake@cmake.org" 
>
Subject: Re: [CMake] Finding all the libraries except for one located in the 
last path dir

Sorry for the spam, but I found out that there is a line break added by CMake


execute_process(COMMAND bash "../grab_libraries.sh" "lib_dirs" "${METHOD}" 
OUTPUT_VARIABLE lib_dirs)


grab_libraries.sh is located in the same folder than CMakeLists.txt and I call 
cmake .. from a build folder inside the same folder than CMakeLists.txt . The 
output for the script ./grab_libraries.sh is:


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


with no line break, whereas the output variable lib_dirs:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


does have a line break and also the semicolons are removed. What’s happening 
here and how can I get rid of that?


Thanks

Miguel


From: Miguel Salazar >
Date: Tuesday, April 5, 2016 at 1:57 PM
To: Miguel Salazar >, 
"cmake@cmake.org" 
>
Subject: Re: [CMake] Finding all the libraries except for one located in the 
last path dir

My apologies, the previous error was because of a trailing whitespace. Although 
I would still like to know why the terminal variable

/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;

is transformed into

/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib

Miguel
From: CMake > on behalf 
of Miguel Salazar >
Date: Tuesday, April 5, 2016 at 12:55 PM
To: "cmake@cmake.org" 
>
Subject: [CMake] Finding all the libraries except for one located in the last 
path dir

Hello

I am calling find_library in a loop, using the same variable for HINTS. This 
variable (lib_dirs) is set using a script, and when I simply print it using 
message(), I obtain this output:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


The variable lib_dirs is the output variable of a script that I call using 
execute_process(). The actual script output (in the terminal) is


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


but cmakes removes all the semicolons and puts them all together, why?


Now when I call find_library() for several libraries, I can find them all 
except the one located in /g/g92/miguel/code/libmesh_2D/lib, why?


Thanks

Miguel



-- 

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] Finding all the libraries except for one located in the last path dir

2016-04-05 Thread Salazar De Troya, Miguel
Sorry for the spam, but I found out that there is a line break added by CMake


execute_process(COMMAND bash "../grab_libraries.sh" "lib_dirs" "${METHOD}" 
OUTPUT_VARIABLE lib_dirs)


grab_libraries.sh is located in the same folder than CMakeLists.txt and I call 
cmake .. from a build folder inside the same folder than CMakeLists.txt . The 
output for the script ./grab_libraries.sh is:


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


with no line break, whereas the output variable lib_dirs:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


does have a line break and also the semicolons are removed. What’s happening 
here and how can I get rid of that?


Thanks

Miguel


From: Miguel Salazar >
Date: Tuesday, April 5, 2016 at 1:57 PM
To: Miguel Salazar >, 
"cmake@cmake.org" 
>
Subject: Re: [CMake] Finding all the libraries except for one located in the 
last path dir

My apologies, the previous error was because of a trailing whitespace. Although 
I would still like to know why the terminal variable

/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;

is transformed into

/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib

Miguel
From: CMake > on behalf 
of Miguel Salazar >
Date: Tuesday, April 5, 2016 at 12:55 PM
To: "cmake@cmake.org" 
>
Subject: [CMake] Finding all the libraries except for one located in the last 
path dir

Hello

I am calling find_library in a loop, using the same variable for HINTS. This 
variable (lib_dirs) is set using a script, and when I simply print it using 
message(), I obtain this output:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


The variable lib_dirs is the output variable of a script that I call using 
execute_process(). The actual script output (in the terminal) is


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


but cmakes removes all the semicolons and puts them all together, why?


Now when I call find_library() for several libraries, I can find them all 
except the one located in /g/g92/miguel/code/libmesh_2D/lib, why?


Thanks

Miguel



-- 

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] Finding all the libraries except for one located in the last path dir

2016-04-05 Thread Salazar De Troya, Miguel
My apologies, the previous error was because of a trailing whitespace. Although 
I would still like to know why the terminal variable

/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;

is transformed into

/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib

Miguel
From: CMake > on behalf 
of Miguel Salazar >
Date: Tuesday, April 5, 2016 at 12:55 PM
To: "cmake@cmake.org" 
>
Subject: [CMake] Finding all the libraries except for one located in the last 
path dir

Hello

I am calling find_library in a loop, using the same variable for HINTS. This 
variable (lib_dirs) is set using a script, and when I simply print it using 
message(), I obtain this output:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


The variable lib_dirs is the output variable of a script that I call using 
execute_process(). The actual script output (in the terminal) is


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


but cmakes removes all the semicolons and puts them all together, why?


Now when I call find_library() for several libraries, I can find them all 
except the one located in /g/g92/miguel/code/libmesh_2D/lib, why?


Thanks

Miguel



-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.1-826-g1fb6c13

2016-04-05 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  1fb6c135300184b2c8ea3e8f0785a7aa13334167 (commit)
   via  add7abc8352b87184579401cb2493c72e07aa212 (commit)
   via  ff805113c766371677b97d94cd3092cf6ff0bbf6 (commit)
  from  5ddcbbbcb8d99efd9b9a43e6b20654af4a791c12 (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=1fb6c135300184b2c8ea3e8f0785a7aa13334167
commit 1fb6c135300184b2c8ea3e8f0785a7aa13334167
Merge: 5ddcbbb add7abc
Author: Brad King 
AuthorDate: Tue Apr 5 16:29:10 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 16:29:10 2016 -0400

Merge topic 'ninja-restat-custom-command-byproducts' into next

add7abc8 Ninja: Restat custom command byproducts even with a SYMBOLIC 
output (#16049)
ff805113 Ninja: Fix detection of custom command symbolic outputs

diff --cc Tests/RunCMake/BuildDepends/RunCMakeTest.cmake
index 6b2b85a,0dd27d4..8541070
--- a/Tests/RunCMake/BuildDepends/RunCMakeTest.cmake
+++ b/Tests/RunCMake/BuildDepends/RunCMakeTest.cmake
@@@ -39,48 -39,5 +39,49 @@@ if(NOT RunCMake_GENERATOR MATCHES "Visu
unset(run_BuildDepends_skip_step_2)
  endif()
  
+ run_BuildDepends(Custom-Symbolic-and-Byproduct)
  run_BuildDepends(Custom-Always)
 +
 +if(RunCMake_GENERATOR MATCHES "Make" AND
 +   NOT "${RunCMake_BINARY_DIR}" STREQUAL "${RunCMake_SOURCE_DIR}")
 +  run_BuildDepends(MakeInProjectOnly)
 +endif()
 +
 +function(run_ReGeneration)
 +  # test re-generation of project even if CMakeLists.txt files disappeared
 +
 +  # Use a single build tree for a few tests without cleaning.
 +  set(RunCMake_TEST_BINARY_DIR 
${RunCMake_BINARY_DIR}/regenerate-project-build)
 +  set(RunCMake_TEST_SOURCE_DIR 
${RunCMake_BINARY_DIR}/regenerate-project-source)
 +  set(RunCMake_TEST_NO_CLEAN 1)
 +  file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
 +  file(REMOVE_RECURSE "${RunCMake_TEST_SOURCE_DIR}")
 +  set(ProjectHeader [=[
 +cmake_minimum_required(VERSION 3.5)
 +project(Regenerate-Project NONE)
 +  ]=])
 +
 +  # create project with subdirectory
 +  file(WRITE "${RunCMake_TEST_SOURCE_DIR}/CMakeLists.txt" "${ProjectHeader}"
 +"add_subdirectory(mysubdir)")
 +  file(MAKE_DIRECTORY "${RunCMake_TEST_SOURCE_DIR}/mysubdir")
 +  file(WRITE "${RunCMake_TEST_SOURCE_DIR}/mysubdir/CMakeLists.txt" "# empty")
 +
 +  run_cmake(Regenerate-Project)
 +  execute_process(COMMAND ${CMAKE_COMMAND} -E sleep ${fs_delay})
 +
 +  # now we delete the subdirectory and adjust the CMakeLists.txt
 +  file(REMOVE_RECURSE "${RunCMake_TEST_SOURCE_DIR}/mysubdir")
 +  file(WRITE "${RunCMake_TEST_SOURCE_DIR}/CMakeLists.txt" "${ProjectHeader}")
 +
 +  run_cmake_command(Regenerate-Project-Directory-Removed
 +${CMAKE_COMMAND} --build "${RunCMake_TEST_BINARY_DIR}")
 +
 +  unset(RunCMake_TEST_BINARY_DIR)
 +  unset(RunCMake_TEST_SOURCE_DIR)
 +  unset(RunCMake_TEST_NO_CLEAN)
 +endfunction()
 +
 +if(RunCMake_GENERATOR STREQUAL "Xcode")
 +  run_ReGeneration(regenerate-project)
 +endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add7abc8352b87184579401cb2493c72e07aa212
commit add7abc8352b87184579401cb2493c72e07aa212
Author: Brad King 
AuthorDate: Tue Apr 5 16:20:28 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 5 16:20:28 2016 -0400

Ninja: Restat custom command byproducts even with a SYMBOLIC output (#16049)

The change in commit v3.5.0-rc1~198^2 (Ninja: Always re-run custom
commands that have symbolic dependencies, 2015-11-19) broke the
byproducts feature added by commit v3.2.0-rc1~340^2~2 (Add an option for
explicit BYPRODUCTS of custom commands, 2014-11-13) when SYMBOLIC
outputs also appear.  This case occurs with AUTORCC-generated custom
targets because the output is SYMBOLIC (to always run) and the generated
file is a byproduct (for restat so dependents do not run unnecessarily).

The two use cases conflict because Ninja does not support per-output
restat.  Favor restat whenever byproducts are present because it is
required for byproducts to work correctly.  In use cases where we want
an always-run chain we simply will not be able to also use byproducts.

diff --git a/Source/cmLocalNinjaGenerator.cxx b/Source/cmLocalNinjaGenerator.cxx
index 6a5949c..2d13507 100644
--- a/Source/cmLocalNinjaGenerator.cxx
+++ b/Source/cmLocalNinjaGenerator.cxx
@@ -444,7 +444,7 @@ cmLocalNinjaGenerator::WriteCustomCommandBuildStatement(
   this->ConstructComment(ccg),
   "Custom command for " + ninjaOutputs[0],
   cc->GetUsesTerminal(),
-  

[CMake] Finding all the libraries except for one located in the last path dir

2016-04-05 Thread Salazar De Troya, Miguel
Hello

I am calling find_library in a loop, using the same variable for HINTS. This 
variable (lib_dirs) is set using a script, and when I simply print it using 
message(), I obtain this output:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


The variable lib_dirs is the output variable of a script that I call using 
execute_process(). The actual script output (in the terminal) is


/usr/lib;/lib;/usr/lib64;/usr/local/tools/vtk-6.1.0/lib;/g/g92/miguel/petsc-3.6.2/miguel-opt/lib;/usr/local/tools/openmpi-intel-1.8.4/lib;/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64;/usr/lib/gcc/x86_64-redhat-linux/4.4.7;/g/g92/miguel/code/libmesh_2D/lib;


but cmakes removes all the semicolons and puts them all together, why?


Now when I call find_library() for several libraries, I can find them all 
except the one located in /g/g92/miguel/code/libmesh_2D/lib, why?


Thanks

Miguel



-- 

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] Parsing command line arguments from the make

2016-04-05 Thread Fedja Jeleskovic
I ended up using this exact approach with addition of one top level
Makefile which is used to run cmake in build folder. Top level Makefile
takes those arguments and passes them down to the cmake execution, which
than makes a decision on which way to go depending on the argument passed
in.

Here is how that part looks like:
BUILD_DIR   :=  build

ifneq ($(ENV),)
DEPLOY=$(ENV)
endif

ifeq "$(DEPLOY)" "V1"
NEW_FLAG=-DVERSION_1=ON
else
ifeq "$(DEPLOY)" "V2"
NEW_FLAG = -DVERSION_2=ON
else
ifeq "$(DEPLOY)" "V3"
NEW_FLAG = -DVERSION_3=ON
endif
endif
endif

all: ${BUILD_DIR}/Makefile
$(MAKE) -C ${BUILD_DIR}

cmake:
touch CMakeLists.txt
$(MAKE) ${BUILD_DIR}/Makefile

${BUILD_DIR}/Makefile:
@[ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR}
@[ -f ${BUILD_DIR}/Makefile ] || (cd ${BUILD_DIR} && cmake $(NEW_FLAG) ..)
touch $@


I have also created three options (needed three in my case) that create
#defines for each of them and depending on which is initialized at the
start, ends up being enabled in the source code.

The issue that I had at the end was to clean cached values of those since
regular clean wasn't clearing #define that was previously set. At the end I
am running "make clean"  in build folder, following with delete of
build/CMakeCache.txt and build/Makefile. After that new option passed in to
the top level Makefile does what I need (initialize proper #define that is).

Here is how the clean section looks like in the top level Makefile:
.PHONY : clean
clean:
@- [ -f ${BUILD_DIR}/Makefile ] && $(MAKE) --silent -C ${BUILD_DIR} clean
|| true
@- [ -f ${BUILD_DIR}/CMakeCache.txt ] && rm ${BUILD_DIR}/CMakeCache.txt ||
true
@- [ -f ${BUILD_DIR}/Makefile ] && rm -rf ${BUILD_DIR}/Makefile || true


If there is a better way to clear the cache so I don't have to delete those
two files, I would like someone to point it.

Thanks for help and hope this will be useful for someone else in the future!

Any other comments on this are welcome!

On Tue, Apr 5, 2016 at 4:36 AM, Matějů Miroslav, Ing. <
mateju.miros...@azd.cz> wrote:

> Hi Fedja,
>
>
>
> As far as I know, the Makefiles generated  from CMake cannot contain
> decisions. CMake supports several output types aside from Makefiles and
> some of them probably don’t support decisions. However, you could supply
> these arguments within CMake call using -D option. For example
>
> cmake -DENV=VERSION_2 
>
> creates a CMake variable just like
>
> set(ENV "VERSION_2" CACHE)
>
> in the CMake source file.
>
>
>
> As you’ve mentioned already, you can access environment variables using
> $ENV{variable} syntax in CMake.
>
>
>
> Hope this helps.
>
>
>
> Miroslav
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Fedja
> Jeleskovic
> *Sent:* Friday, April 01, 2016 8:08 PM
> *To:* cmake@cmake.org
> *Subject:* [CMake] Parsing command line arguments from the make
>
>
>
> Since I am converting existing makefile project to use cmake instead I
> need to accept values that come from command line which looks like this:
> VARIABLE_NAME="/home/user/project" make ENV=VERSION_2
>
>
>
> First one is used like this:
>
> include $(VARIABLE_NAME)/Makefile.include
>
>
>
> Second one has this code that triggers different paths later:
> ifneq ($(ENV),)
>
> DEPLOYMENT_VERSION=$(ENV)
>
> endif
>
>
>
> How do I do this in cmake?
>
>
>
> Thanks!
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016049]: Resources generated with autorcc are always rebuilt using ninja

2016-04-05 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16049 
== 
Reported By:Vidar Meland Ødegård
Assigned To:
== 
Project:CMake
Issue ID:   16049
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   high
Status: new
== 
Date Submitted: 2016-04-05 14:49 EDT
Last Modified:  2016-04-05 14:49 EDT
== 
Summary:Resources generated with autorcc are always rebuilt
using ninja
Description: 
By using ninja and autorcc the resources are always rebuilt on CMake >= 3.5.
CMake 3.4.3 does not have this issue.

Steps to Reproduce: 
cmake  -GNinja
ninja -v
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-05 14:49 Vidar Meland ØdegårdNew Issue
   
2016-04-05 14:49 Vidar Meland ØdegårdFile Added: bug.tar.gz   
   
==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

2016-04-05 Thread Ruslan Baratov via cmake-developers

On 05-Apr-16 21:03, Brad King wrote:

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:

What about 3 properties containing list of 's (groups
unexpanded):

* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

We would need to define behavior when a warning appears in more than
one list.


Report an error in case of any type of conflicts. It may happens not 
only when same type appears in both DISABLE and ENABLE but for example 
when warning already defined by some group. E.g. "EVERYTHING;undef" is 
the same as "EVERYTHING". If user okay with having intersections (for 
any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may 
control this.



   Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.


You mean this:

compatibility-c++98=off
inline=off
special-members=off
catch-semantic-changed=off
covered-switch-default=off
inherits-via-dominance=off
name-length-exceeded=off
padded=off
this-used-in-init=off
EVERYTHING=on
EVERYTHING=error

versus this one:

DISABLE
  compatibility-c++98
  inline
  special-members
  catch-semantic-changed
  covered-switch-default
  inherits-via-dominance
  name-length-exceeded
  padded
  this-used-in-init
ENABLE
  EVERYTHING
TREAT_AS_ERROR
  EVERYTHING

?

Second variant looks clearer for me.



The name "ALL" may not be representative.  Even -Wall does not really enable
all possible warnings on some compilers.  I'd like to find another name that
captures the idea of enabling most warnings.  Or we could try to subsume it
into an interface for the warning level, with -Wall considered "high".


Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?




I'm not sure about mixing more languages. I think it will be similar to
COMPILE_OPTIONS (?), see no language specification in
`add_compile_options` command.

Right.  We do have the COMPILE_LANGUAGE genex for some limited use cases.
Its documentation even includes a COMPILE_OPTIONS example.  However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.


Since /Wall can be set by 'target_compile_options' then abstracting it 
by `target_compile_warnings(... ENABLE ALL)` should not be a problem I 
think.




Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.


See no point of this one. So say we have switch-enum warning which is 
only for C++, why do we need cxx-switch-enum? There is no c-switch-enum 
or any other *-switch-enum. If we are talking about 'undef' why do we 
need c-undef and cxx-undef? It mean the same and I think will be set or 
unset simultaneously.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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


[Cmake-commits] CMake branch, next, updated. v3.5.1-823-g5ddcbbb

2016-04-05 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  5ddcbbbcb8d99efd9b9a43e6b20654af4a791c12 (commit)
   via  f831d752aeb3000a9b1b686da986af7ffecb6968 (commit)
  from  70ae13e6720ca49711c2afa36fcc7e036bd91432 (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=5ddcbbbcb8d99efd9b9a43e6b20654af4a791c12
commit 5ddcbbbcb8d99efd9b9a43e6b20654af4a791c12
Merge: 70ae13e f831d75
Author: Brad King 
AuthorDate: Tue Apr 5 13:12:08 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 13:12:08 2016 -0400

Merge topic 'fortran-line-directives-no-dirs' into next

f831d752 cmFortranParser: Skip #line directives that do not name files


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f831d752aeb3000a9b1b686da986af7ffecb6968
commit f831d752aeb3000a9b1b686da986af7ffecb6968
Author: Brad King 
AuthorDate: Tue Apr 5 12:57:15 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 5 12:59:45 2016 -0400

cmFortranParser: Skip #line directives that do not name files

Since commit v3.5.0-rc1~241^2~1 (cmFortranParser: Parse #line
directives, 2015-11-02) our Fortran dependency scanner parses `#line`
directives to extract the named files.  However, some compilers produce
`#line` directives that name directories instead of files.  Work around
such cases by verifying that the extracted path names a file and not a
directory.

diff --git a/Source/cmFortranParserImpl.cxx b/Source/cmFortranParserImpl.cxx
index c175e62..b3b2f16 100644
--- a/Source/cmFortranParserImpl.cxx
+++ b/Source/cmFortranParserImpl.cxx
@@ -229,7 +229,7 @@ void cmFortranParser_RuleLineDirective(cmFortranParser* 
parser,
   cmSystemTools::ConvertToUnixSlashes(included);
 
   // Save the named file as included in the source.
-  if (cmSystemTools::FileExists(included))
+  if (cmSystemTools::FileExists(included, true))
 {
 parser->Info.Includes.insert(included);
 }

---

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


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


[Cmake-commits] CMake branch, next, updated. v3.5.1-821-g70ae13e

2016-04-05 Thread Zack Galbreath
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  70ae13e6720ca49711c2afa36fcc7e036bd91432 (commit)
   via  1c92713c64e8d85804a7f6fe3dcf936e36b08101 (commit)
   via  d32313426b4744823b0afd240223dce0aaef6bd8 (commit)
  from  42c8dec332620edce95b558c57173ad1c04fb340 (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=70ae13e6720ca49711c2afa36fcc7e036bd91432
commit 70ae13e6720ca49711c2afa36fcc7e036bd91432
Merge: 42c8dec 1c92713
Author: Zack Galbreath 
AuthorDate: Tue Apr 5 12:15:17 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 12:15:17 2016 -0400

Merge topic 'branch_coverage_glob' into next

1c92713c CTestCoverageCollectGCOV: fix in-source test
d3231342 CTestCoverageCollectGCOV: exclude uncovered files


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c92713c64e8d85804a7f6fe3dcf936e36b08101
commit 1c92713c64e8d85804a7f6fe3dcf936e36b08101
Author: Zack Galbreath 
AuthorDate: Tue Apr 5 11:58:09 2016 -0400
Commit: Zack Galbreath 
CommitDate: Tue Apr 5 12:14:03 2016 -0400

CTestCoverageCollectGCOV: fix in-source test

Fix the test of this module for in-source builds by excluding
the CMakeFiles directory from our results.

diff --git a/Tests/CTestCoverageCollectGCOV/test.cmake.in 
b/Tests/CTestCoverageCollectGCOV/test.cmake.in
index ec32113..d48ef61 100644
--- a/Tests/CTestCoverageCollectGCOV/test.cmake.in
+++ b/Tests/CTestCoverageCollectGCOV/test.cmake.in
@@ -15,6 +15,7 @@ list(APPEND CTEST_CUSTOM_COVERAGE_EXCLUDE
   "/foo/something"
   "/3rdparty/"
   "/bar/somethingelse"
+  "/CMakeFiles/"
 )
 list(APPEND CTEST_EXTRA_COVERAGE_GLOB "*.cpp")
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d32313426b4744823b0afd240223dce0aaef6bd8
commit d32313426b4744823b0afd240223dce0aaef6bd8
Author: Zack Galbreath 
AuthorDate: Tue Apr 5 12:09:18 2016 -0400
Commit: Zack Galbreath 
CommitDate: Tue Apr 5 12:12:24 2016 -0400

CTestCoverageCollectGCOV: exclude uncovered files

Any uncovered files found by CTEST_EXTRA_COVERAGE_GLOB are now
subject to the exclusion filters set in CTEST_CUSTOM_COVERAGE_EXCLUDE.

diff --git a/Modules/CTestCoverageCollectGCOV.cmake 
b/Modules/CTestCoverageCollectGCOV.cmake
index 7d387a5..ed21384 100644
--- a/Modules/CTestCoverageCollectGCOV.cmake
+++ b/Modules/CTestCoverageCollectGCOV.cmake
@@ -227,6 +227,21 @@ function(ctest_coverage_collect_gcov)
   endforeach()
 
   foreach (uncovered_file ${uncovered_files})
+# Check if this uncovered file should be excluded.
+set(is_excluded false)
+foreach(exclude_entry IN LISTS CTEST_CUSTOM_COVERAGE_EXCLUDE)
+  if(uncovered_file MATCHES "${exclude_entry}")
+set(is_excluded true)
+if(NOT GCOV_QUIET)
+  message("Excluding coverage for: ${uncovered_file} which matches 
${exclude_entry}")
+endif()
+break()
+  endif()
+endforeach()
+if(is_excluded)
+  continue()
+endif()
+
 # Copy from source to binary dir, preserving any intermediate 
subdirectories.
 get_filename_component(filename "${uncovered_file}" NAME)
 get_filename_component(relative_path "${uncovered_file}" DIRECTORY)

---

Summary of changes:
 Modules/CTestCoverageCollectGCOV.cmake   |   15 +++
 Tests/CTestCoverageCollectGCOV/test.cmake.in |1 +
 2 files changed, 16 insertions(+)


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


Re: [cmake-developers] for C# language support

2016-04-05 Thread Brad King
On 04/04/2016 04:08 PM, Adam Treat via cmake-developers wrote:
> I have been working on improving the cmake language module for C# found here:

Thanks for working on this.  I'm adding Michael Stuermer to Cc who has
been working on support in the VS IDE generators:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15753/focus=16064

> One thing that has me a bit flummoxed is how to implement the following:
> 
> CMAKE_CSharp_CREATE_SHARED_LIBRARY
> CMAKE_CSharp_CREATE_SHARED_MODULE
> CMAKE_CSharp_CREATE_STATIC_LIBRARY
> 
> in CMakeCSharpInformation.cmake.  In C# libraries need to have all symbols 
> resolved
> at creation time just like executables and this means I need access to the 
> LINK_LIBRARIES
> property to correctly implement the above.  However, it seems this property 
> is empty
> for the above.

It is expected to be available for at least the shared/module link rules.
See cmMakefileTargetGenerator::CreateLinkLibs's implementation and its
call sites.  Also see cmLocalGenerator::ExpandRuleVariable for where
the placeholders like  get expanded.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH v2] language detection in FindBLAS and FindLAPACK (#0016039)

2016-04-05 Thread Brad King
On 04/03/2016 05:21 PM, melven.roehrig-zoell...@dlr.de wrote:
> Updated patch for a problem with find_package(BLAS/LAPACK)
> on Windows for pure Fortran projects.
> Now simply uses CMAKE__COMPILER_LOADED...

Thanks!  Applied:

 Find{BLAS,LAPACK}: Fix when used in pure Fortran projects (#16039)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1694112d

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64

2016-04-05 Thread Brad King
On 04/05/2016 04:48 AM, melven.roehrig-zoell...@dlr.de wrote:
> Requested changes from Ben Boeckel,
> also adjusted the similar if("${...}" MATCHES ...) statements in the section 
> above.

Thanks.  Applied:

 CMakeDetermineFortranCompiler: Modernize conventions
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66fa6143

 Fortran: Fix platform id detection on mingw-w64
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c4f100a

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] CMake API for warnings

2016-04-05 Thread Brad King
On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
> What about 3 properties containing list of 's (groups 
> unexpanded):
> 
> * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
> * COMPILE_WARNINGS_ENABLE # e.g. "ALL"
> * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

We would need to define behavior when a warning appears in more than
one list.  Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.

The name "ALL" may not be representative.  Even -Wall does not really enable
all possible warnings on some compilers.  I'd like to find another name that
captures the idea of enabling most warnings.  Or we could try to subsume it
into an interface for the warning level, with -Wall considered "high".

> I'm not sure about mixing more languages. I think it will be similar to 
> COMPILE_OPTIONS (?), see no language specification in 
> `add_compile_options` command.

Right.  We do have the COMPILE_LANGUAGE genex for some limited use cases.
Its documentation even includes a COMPILE_OPTIONS example.  However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.

Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


[Cmake-commits] CMake branch, next, updated. v3.5.1-818-g42c8dec

2016-04-05 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  42c8dec332620edce95b558c57173ad1c04fb340 (commit)
   via  2308764b476d6f6c399fe6a22bb0545d511bdbb1 (commit)
  from  576f741379fcd9201791204619ad01d13c908903 (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=42c8dec332620edce95b558c57173ad1c04fb340
commit 42c8dec332620edce95b558c57173ad1c04fb340
Merge: 576f741 2308764
Author: Brad King 
AuthorDate: Tue Apr 5 09:53:08 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:53:08 2016 -0400

Merge topic 'FindGSL-doc-typo' into next

2308764b FindGSL: Fix typo in documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2308764b476d6f6c399fe6a22bb0545d511bdbb1
commit 2308764b476d6f6c399fe6a22bb0545d511bdbb1
Author: Pierrick Koch 
AuthorDate: Mon Apr 4 16:35:50 2016 +0200
Commit: Brad King 
CommitDate: Tue Apr 5 09:52:43 2016 -0400

FindGSL: Fix typo in documentation

s/GSL_CLBAS_LIBRARY/GSL_CBLAS_LIBRARY/

diff --git a/Modules/FindGSL.cmake b/Modules/FindGSL.cmake
index ef125c0..9318a7d 100644
--- a/Modules/FindGSL.cmake
+++ b/Modules/FindGSL.cmake
@@ -45,7 +45,7 @@
 # of GSL installation discovered.  These variables may optionally be set to
 # help this module find the correct files::
 #
-#  GSL_CLBAS_LIBRARY   - Location of the GSL CBLAS library.
+#  GSL_CBLAS_LIBRARY   - Location of the GSL CBLAS library.
 #  GSL_CBLAS_LIBRARY_DEBUG - Location of the debug GSL CBLAS library (if any).
 #  GSL_CONFIG_EXECUTABLE   - Location of the ``gsl-config`` script (if any).
 #  GSL_LIBRARY - Location of the GSL library.

---

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


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


[Cmake-commits] CMake branch, next, updated. v3.5.1-816-g576f741

2016-04-05 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  576f741379fcd9201791204619ad01d13c908903 (commit)
   via  8c4f100a56619bf115115d0bcaa322c422f0c44f (commit)
   via  66fa61439db3043e903074a526aa2200e9766dcc (commit)
  from  3a8811f9c69a5ca9c441e79c0c3c790670dc1066 (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=576f741379fcd9201791204619ad01d13c908903
commit 576f741379fcd9201791204619ad01d13c908903
Merge: 3a8811f 8c4f100
Author: Brad King 
AuthorDate: Tue Apr 5 09:50:56 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:50:56 2016 -0400

Merge topic 'mingw-w64-Fortran-platform' into next

8c4f100a Fortran: Fix platform id detection on mingw-w64
66fa6143 CMakeDetermineFortranCompiler: Modernize conventions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c4f100a56619bf115115d0bcaa322c422f0c44f
commit 8c4f100a56619bf115115d0bcaa322c422f0c44f
Author: Melven Roehrig-Zoellner 
AuthorDate: Sun Apr 3 23:01:22 2016 +0200
Commit: Brad King 
CommitDate: Tue Apr 5 09:50:14 2016 -0400

Fortran: Fix platform id detection on mingw-w64

On mingw-w64 the GNU Fortran compiler does not define `__MINGW32__` or
any similar indicator.  Fix `CMAKE_Fortran_PLATFORM_ID` detection in
this case by falling back to preprocessing a `.c` source file even
when the compiler id is already detected.

diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index 1baca29..4f2a70c 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -209,6 +209,21 @@ if(NOT CMAKE_Fortran_COMPILER_ID_RUN)
 endif()
   endif()
 
+  # Fall back for GNU MINGW, which is not always detected correctly
+  # (__MINGW32__ is defined for the C language, but perhaps not for Fortran!)
+  if(CMAKE_Fortran_COMPILER_ID MATCHES "GNU" AND NOT CMAKE_Fortran_PLATFORM_ID)
+execute_process(COMMAND ${CMAKE_Fortran_COMPILER} 
${CMAKE_Fortran_COMPILER_ID_FLAGS_LIST} -E 
"${CMAKE_ROOT}/Modules/CMakeTestGNU.c"
+  OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT RESULT_VARIABLE 
CMAKE_COMPILER_RETURN)
+if(NOT CMAKE_COMPILER_RETURN)
+  if(CMAKE_COMPILER_OUTPUT MATCHES "THIS_IS_MINGW")
+set(CMAKE_Fortran_PLATFORM_ID "MinGW")
+  endif()
+  if(CMAKE_COMPILER_OUTPUT MATCHES "THIS_IS_CYGWIN")
+set(CMAKE_Fortran_PLATFORM_ID "Cygwin")
+  endif()
+endif()
+  endif()
+
   # Set old compiler and platform id variables.
   if(CMAKE_Fortran_COMPILER_ID MATCHES "GNU")
 set(CMAKE_COMPILER_IS_GNUG77 1)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66fa61439db3043e903074a526aa2200e9766dcc
commit 66fa61439db3043e903074a526aa2200e9766dcc
Author: Melven Roehrig-Zoellner 
AuthorDate: Sun Apr 3 23:01:22 2016 +0200
Commit: Brad King 
CommitDate: Tue Apr 5 09:44:09 2016 -0400

CMakeDetermineFortranCompiler: Modernize conventions

Suggested-by: Ben Boeckel 

diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index ccafb07..1baca29 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -185,11 +185,10 @@ if(NOT CMAKE_Fortran_COMPILER_ID_RUN)
 
   # Fall back to old is-GNU test.
   if(NOT CMAKE_Fortran_COMPILER_ID)
-exec_program(${CMAKE_Fortran_COMPILER}
-  ARGS ${CMAKE_Fortran_COMPILER_ID_FLAGS_LIST} -E 
"\"${CMAKE_ROOT}/Modules/CMakeTestGNU.c\""
-  OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT RETURN_VALUE CMAKE_COMPILER_RETURN)
+execute_process(COMMAND ${CMAKE_Fortran_COMPILER} 
${CMAKE_Fortran_COMPILER_ID_FLAGS_LIST} -E 
"${CMAKE_ROOT}/Modules/CMakeTestGNU.c"
+  OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT RESULT_VARIABLE 
CMAKE_COMPILER_RETURN)
 if(NOT CMAKE_COMPILER_RETURN)
-  if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_GNU")
+  if(CMAKE_COMPILER_OUTPUT MATCHES "THIS_IS_GNU")
 set(CMAKE_Fortran_COMPILER_ID "GNU")
 file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
   "Determining if the Fortran compiler is GNU succeeded with "
@@ -200,10 +199,10 @@ if(NOT CMAKE_Fortran_COMPILER_ID_RUN)
   "the following output:\n${CMAKE_COMPILER_OUTPUT}\n\n")
   endif()
   if(NOT CMAKE_Fortran_PLATFORM_ID)
-if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_MINGW")
+if(CMAKE_COMPILER_OUTPUT 

[Cmake-commits] CMake branch, master, updated. v3.5.1-379-gadea45e

2016-04-05 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  adea45e15abf95b53e13ea8564cad9fc8e35ed56 (commit)
   via  0e44f4894f23d5eccd8d360f3420c832f9433a20 (commit)
   via  bc30f8b5e66cb9c15fd224f5e51454c0bc66c67e (commit)
  from  6c60f116cb2bfe6753f526ceacfb5e54bc22efc5 (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=adea45e15abf95b53e13ea8564cad9fc8e35ed56
commit adea45e15abf95b53e13ea8564cad9fc8e35ed56
Merge: 6c60f11 0e44f48
Author: Brad King 
AuthorDate: Tue Apr 5 09:37:59 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:37:59 2016 -0400

Merge topic 'fix-target-alias-in-subdir'

0e44f489 Rename local target lookup methods to clarify purpose
bc30f8b5 Fix lookup of an ALIAS target outside aliased target's directory 
(#16044)


---

Summary of changes:
 Source/cmFLTKWrapUICommand.cxx  |2 +-
 Source/cmInstallCommand.cxx |2 +-
 Source/cmInstallTargetGenerator.cxx |2 +-
 Source/cmLocalGenerator.cxx |   15 ++-
 Source/cmLocalGenerator.h   |3 ++-
 Source/cmMakefile.cxx   |   16 ++--
 Source/cmMakefile.h |3 +--
 Tests/AliasTarget/subdir/CMakeLists.txt |5 +
 8 files changed, 15 insertions(+), 33 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, master, updated. v3.5.1-388-gfd40b0f

2016-04-05 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  fd40b0f875db35b9eaf214fd1013277d1801d589 (commit)
   via  c18d91add836f7ce426fcb59b2c65235898f3979 (commit)
   via  7f5607439ed0d1303265d3db0937e90683e698de (commit)
   via  06b310b5d5d8a38fb17df02fee8df750904cfcd0 (commit)
   via  56c1ea40c5e278155025f3823089e2d0fa34054a (commit)
  from  25a38ecfe7beffe2a2adf522414288810cdc1006 (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=fd40b0f875db35b9eaf214fd1013277d1801d589
commit fd40b0f875db35b9eaf214fd1013277d1801d589
Merge: 25a38ec c18d91a
Author: Brad King 
AuthorDate: Tue Apr 5 09:38:06 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:38:06 2016 -0400

Merge topic 'ctest-run-submodule-sync'

c18d91ad Help: add release notes for topic 'ctest-run-submodule-sync'
7f560743 cmCTestGIT: run `git submodule sync` before updating submodules
06b310b5 cmCTestGIT: add an option to initialize submodules on update
56c1ea40 cmCTestGIT: fix git version references


---

Summary of changes:
 Help/manual/cmake-variables.7.rst  |1 +
 Help/manual/ctest.1.rst|6 +++
 Help/release/dev/ctest-run-submodule-sync.rst  |9 
 ...SION_ONLY.rst => CTEST_GIT_INIT_SUBMODULES.rst} |4 +-
 Modules/DartConfiguration.tcl.in   |1 +
 Source/CTest/cmCTestGIT.cxx|   47 ++--
 Source/CTest/cmCTestUpdateCommand.cxx  |2 +
 7 files changed, 64 insertions(+), 6 deletions(-)
 create mode 100644 Help/release/dev/ctest-run-submodule-sync.rst
 copy Help/variable/{CTEST_UPDATE_VERSION_ONLY.rst => 
CTEST_GIT_INIT_SUBMODULES.rst} (50%)


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.5.1-390-g73efdd4

2016-04-05 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  73efdd46555b3236ade1f4431eb9653166b5c97f (commit)
   via  58a57105d04564a954256f8441809a4e33a3cb67 (commit)
  from  fd40b0f875db35b9eaf214fd1013277d1801d589 (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 -
---

Summary of changes:


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


[Cmake-commits] CMake branch, next, updated. v3.5.1-810-g0b329ba

2016-04-05 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  0b329baad63a5f4639ce96e12dbf8e73484d74dd (commit)
   via  fd40b0f875db35b9eaf214fd1013277d1801d589 (commit)
   via  25a38ecfe7beffe2a2adf522414288810cdc1006 (commit)
   via  b66a2472321d3a261961de75d9613a5a1ecefb37 (commit)
   via  adea45e15abf95b53e13ea8564cad9fc8e35ed56 (commit)
   via  6c60f116cb2bfe6753f526ceacfb5e54bc22efc5 (commit)
  from  dd6882100ef94002e69e767aeb1dee6bb5c837a3 (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=0b329baad63a5f4639ce96e12dbf8e73484d74dd
commit 0b329baad63a5f4639ce96e12dbf8e73484d74dd
Merge: dd68821 fd40b0f
Author: Brad King 
AuthorDate: Tue Apr 5 09:38:23 2016 -0400
Commit: Brad King 
CommitDate: Tue Apr 5 09:38:23 2016 -0400

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.5.1-383-g25a38ec

2016-04-05 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  25a38ecfe7beffe2a2adf522414288810cdc1006 (commit)
   via  398b8800e350a0330be32046a6eed5c146a9f67a (commit)
  from  b66a2472321d3a261961de75d9613a5a1ecefb37 (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=25a38ecfe7beffe2a2adf522414288810cdc1006
commit 25a38ecfe7beffe2a2adf522414288810cdc1006
Merge: b66a247 398b880
Author: Brad King 
AuthorDate: Tue Apr 5 09:38:04 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:38:04 2016 -0400

Merge topic 'cobertura_off_by_one'

398b8800 cmParseCoberturaCoverage: Remove extra coverage line


---

Summary of changes:
 Source/CTest/cmParseCoberturaCoverage.cxx |1 -
 1 file changed, 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.5.1-381-gb66a247

2016-04-05 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  b66a2472321d3a261961de75d9613a5a1ecefb37 (commit)
   via  272779ce6aa4dbf15e2791ca3f3f5cbf1ce57b39 (commit)
  from  adea45e15abf95b53e13ea8564cad9fc8e35ed56 (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=b66a2472321d3a261961de75d9613a5a1ecefb37
commit b66a2472321d3a261961de75d9613a5a1ecefb37
Merge: adea45e 272779c
Author: Brad King 
AuthorDate: Tue Apr 5 09:38:02 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:38:02 2016 -0400

Merge topic 'ep-tls-verify-git'

272779ce ExternalProject: Allow TLS_VERIFY for git clones


---

Summary of changes:
 Help/release/dev/ep-tls-verify-git.rst |5 +
 Modules/ExternalProject.cmake  |   23 +--
 2 files changed, 22 insertions(+), 6 deletions(-)
 create mode 100644 Help/release/dev/ep-tls-verify-git.rst


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


[Cmake-commits] CMake branch, next, updated. v3.5.1-804-gdd68821

2016-04-05 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  dd6882100ef94002e69e767aeb1dee6bb5c837a3 (commit)
   via  b148440381df0143a665b7ceebe8606a052e2cdf (commit)
  from  08e5b04dde6d60a6663a8fce4525f471830fb024 (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=dd6882100ef94002e69e767aeb1dee6bb5c837a3
commit dd6882100ef94002e69e767aeb1dee6bb5c837a3
Merge: 08e5b04 b148440
Author: Brad King 
AuthorDate: Tue Apr 5 09:36:19 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Apr 5 09:36:19 2016 -0400

Merge topic 'FindOpenSSL-names-per-dir' into next

b1484403 FindOpenSSL: Prefer libs early in search path regardless of name 
(#15887)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b148440381df0143a665b7ceebe8606a052e2cdf
commit b148440381df0143a665b7ceebe8606a052e2cdf
Author: Hannes Mezger 
AuthorDate: Mon Apr 4 14:23:23 2016 +0200
Commit: Brad King 
CommitDate: Tue Apr 5 09:32:08 2016 -0400

FindOpenSSL: Prefer libs early in search path regardless of name (#15887)

Add NAMES_PER_DIR to all find_library invocations so that we consider
all possible names in each search directory before moving on to the next
directory.  Otherwise we may not find self-built libraries first even if
they appear early in the search path.

diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
index 8b4b988..8dbaf11 100644
--- a/Modules/FindOpenSSL.cmake
+++ b/Modules/FindOpenSSL.cmake
@@ -151,6 +151,7 @@ if(WIN32 AND NOT CYGWIN)
   NAMES
 libeay32${_OPENSSL_MSVC_RT_MODE}d
 libeay32d
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 ${_OPENSSL_PATH_SUFFIXES}
@@ -160,6 +161,7 @@ if(WIN32 AND NOT CYGWIN)
   NAMES
 libeay32${_OPENSSL_MSVC_RT_MODE}
 libeay32
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 ${_OPENSSL_PATH_SUFFIXES}
@@ -169,6 +171,7 @@ if(WIN32 AND NOT CYGWIN)
   NAMES
 ssleay32${_OPENSSL_MSVC_RT_MODE}d
 ssleay32d
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 ${_OPENSSL_PATH_SUFFIXES}
@@ -179,6 +182,7 @@ if(WIN32 AND NOT CYGWIN)
 ssleay32${_OPENSSL_MSVC_RT_MODE}
 ssleay32
 ssl
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 ${_OPENSSL_PATH_SUFFIXES}
@@ -205,6 +209,7 @@ if(WIN32 AND NOT CYGWIN)
 find_library(LIB_EAY
   NAMES
 ${LIB_EAY_NAMES}
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 "lib"
@@ -214,6 +219,7 @@ if(WIN32 AND NOT CYGWIN)
 find_library(SSL_EAY
   NAMES
 ${SSL_EAY_NAMES}
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   PATH_SUFFIXES
 "lib"
@@ -231,6 +237,7 @@ if(WIN32 AND NOT CYGWIN)
 find_library(LIB_EAY
   NAMES
 libeay32
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   HINTS
 ${_OPENSSL_LIBDIR}
@@ -241,6 +248,7 @@ if(WIN32 AND NOT CYGWIN)
 find_library(SSL_EAY
   NAMES
 ssleay32
+  NAMES_PER_DIR
   ${_OPENSSL_ROOT_HINTS_AND_PATHS}
   HINTS
 ${_OPENSSL_LIBDIR}
@@ -260,6 +268,7 @@ else()
   ssl
   ssleay32
   ssleay32MD
+NAMES_PER_DIR
 ${_OPENSSL_ROOT_HINTS_AND_PATHS}
 HINTS
   ${_OPENSSL_LIBDIR}
@@ -270,6 +279,7 @@ else()
   find_library(OPENSSL_CRYPTO_LIBRARY
 NAMES
   crypto
+NAMES_PER_DIR
 ${_OPENSSL_ROOT_HINTS_AND_PATHS}
 HINTS
   ${_OPENSSL_LIBDIR}

---

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


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


Re: [cmake-developers] ninja/make compilation response file

2016-04-05 Thread Dmitry Ivanov
>Teaching the Ninja generator about response files for object file compilation 
>would be the way to go (and support for RC as well would be good since the 
>logic is likely the same).

I will time box it and see if I can do it in few days, if not we need to figure 
out if it can be done like a sponsored feature or something.
Actually same story with make file generators, doesn't look like they support 
response files for obj either.

>There was work to reduce the size of the generated build.ninja file.
>More work could be done, but the projects I was looking at would only get 
>marginal improvements from other techniques (though other projects with 
>different flag quantities might >show other things to improve). What version 
>of CMake are you using?

3.5.1 atm, 84 mb takes around 3-4 seconds for ninja to parse on my machine, 
which makes ninja slightly useless an fast incremental builds tool, which is a 
shame.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] ninja/make compilation response file

2016-04-05 Thread Dmitry Ivanov
Just checked the size that we are getting, it's 20 Mb for all Makefile and 
*.make combined, and 84 mb build.ninja

From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Monday, April 4, 2016 18:57
To: Dmitry Ivanov ; cmake-developers@cmake.org
Subject: Re: [cmake-developers] ninja/make compilation response file

On 04.04.2016 18:38, Nils Gladitz wrote:
On 04.04.2016 17:59, Dmitry Ivanov wrote:

PS. Can we do something about bloated cmake ninja generator ? in our case cmake 
generates 1.8 Mb Makefile and 84 Mb build.ninja, though ninja is still faster 
than make even in this case.

Curious. Did you count the accumulative size of all Makefile and Makefile2 
files (also in sub-directories)?
For a project of mine the ninja files are only half in size of what is 
generated for the Makefile generator (CMake 3.5.1).

Oh and the Makefile generator also uses build.make files which actually seem to 
be where most of the size goes.

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-developers

[cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64

2016-04-05 Thread Melven.Roehrig-Zoellner
Requested changes from Ben Boeckel,
also adjusted the similar if("${...}" MATCHES ...) statements in the section 
above.

Regards

Melven
--
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany

Melven Röhrig-Zöllner 
Telephone +492203 / 601 - 2574
www.DLR.de







0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch
Description: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Parsing command line arguments from the make

2016-04-05 Thread Matějů Miroslav , Ing .
Hi Fedja,

As far as I know, the Makefiles generated  from CMake cannot contain decisions. 
CMake supports several output types aside from Makefiles and some of them 
probably don’t support decisions. However, you could supply these arguments 
within CMake call using -D option. For example
cmake -DENV=VERSION_2 
creates a CMake variable just like
set(ENV "VERSION_2" CACHE)
in the CMake source file.

As you’ve mentioned already, you can access environment variables using 
$ENV{variable} syntax in CMake.

Hope this helps.

Miroslav

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Fedja Jeleskovic
Sent: Friday, April 01, 2016 8:08 PM
To: cmake@cmake.org
Subject: [CMake] Parsing command line arguments from the make

Since I am converting existing makefile project to use cmake instead I need to 
accept values that come from command line which looks like this:
VARIABLE_NAME="/home/user/project" make ENV=VERSION_2

First one is used like this:
include $(VARIABLE_NAME)/Makefile.include

Second one has this code that triggers different paths later:
ifneq ($(ENV),)
DEPLOYMENT_VERSION=$(ENV)
endif

How do I do this in cmake?

Thanks!
-- 

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] Check the existence of a header / ability to compile source file

2016-04-05 Thread Attila Krasznahorkay
Dear All,

I'm stumped on the following, seemingly simple issue.

I need to figure out in my configuration whether a given header file will be 
available when I'll try to build my library, or not. So that I could set a 
particular definition for the compiler according to whether the file is 
available or not.

The complication is that I use generator expressions very heavily in setting up 
the compilation flags of the library in question. So at configuration time I 
don't even know yet all the include directories that I should be looking in to 
find that header. That only becomes known after the generation step.

But as far as I can tell, check_include_files(...) can only run during the 
configuration step. So relying on generator expressions in setting up its 
include directories is not an option.

Is there any other possibility of making such a check, during the generation 
step? Or is there some other mechanism that I could use to do this check during 
the build itself? (After all, it could be a solution to generate a 
configuration header with this information during the build itself...)

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