date:20150831

Re: [cmake-developers] [PATCH] Add a test for checking that the CPack module produces correct config files

2015-08-31 Thread Domen Vrankar

> My motivation is this. I want to submit a few improvements to the way CPack
> writes config files, starting with that cpack_set_if_not_set change I
> mentioned a while back. This functionality is generator-independent (and
> basically unrelated to actual package generation), so I thought
> RunCMake.CPack was not the appropriate place to test it.

Yes you're right, RunCMake.CPack is meant for specific generators and
adding target 'none' or something similar would just make a mess.

> Since there doesn't seem to be a test suite specifically for config file
> writing, I thought I'd create one in a separate patch so that my later
> patches don't have as much boilerplate in them. The Simple test is just
> there to ensure I don't break the simple case while changing the more
> complex ones. Well, and it would be silly to submit a test suite with no
> tests in it.

I've added your test:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=674dc0b

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] [PATCH] Fix a few issues in FindHDF5 module

2015-08-31 Thread Paul Romano

Thanks for the suggestions, Brad. Here is a set of three patches that
breaks out the changes. For the HDF5_PREFER_PARALLEL implementation, I now
use a list to set the names for find_program which does look much cleaner.
I agree that having a NAMES_PER_DIR for find_program would be simpler from
the user's end. However, as I'm unfamiliar with the C++ source, it would
take me much longer to figure out how to add the necessary changes, so I'll
leave you with the module patches for now.

Best,
Paul

On Tue, Sep 1, 2015 at 1:53 AM, Brad King  wrote:

> On 08/31/2015 04:47 AM, Paul Romano wrote:
> > I'd like to offer the attached patch for consideration
>
> Thanks for working on these changes.
>
> Please split each independent fix out into its own commit with
> corresponding commit message explaining the change.
>
> For the HDF5_PREFER_PARALLEL implementation, please re-use
> the existing find_program calls but simply prepare a variable
> ahead of time that lists the preferred order of names.  OTOH,
> there is another approach to solve this.  The find_library
> command has a NAMES_PER_DIR option that says to consider all
> the given names in each directory before moving on to the next
> directory.  If find_program had this too then one would be able
> to choose a preference simply by having one come first in PATH.
>
> -Brad
>
>
From c6feaa82b0b9fc8a2877cec04b3619adfeea15d7 Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Tue, 1 Sep 2015 09:18:51 +0700
Subject: [PATCH 1/3] FindHDF5: Bring patch from debian cmake-data package
 upstream

Define HDF5_{Fortran_,}HL_COMPILE_LINE so that HDF5_{Fortran_,}HL_INCLUDE_DIR
and HDF5_{Fortran_,}HL_LIBRARIES are found when the macro is invoked for HL and
Fortran_HL components.
---
 Modules/FindHDF5.cmake | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 3bd6f1e..47d85f7 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -225,6 +225,8 @@ if( NOT HDF5_FOUND )
 _HDF5_invoke_compiler( C HDF5_C_COMPILE_LINE HDF5_C_RETURN_VALUE )
 _HDF5_invoke_compiler( CXX HDF5_CXX_COMPILE_LINE HDF5_CXX_RETURN_VALUE )
 _HDF5_invoke_compiler( Fortran HDF5_Fortran_COMPILE_LINE HDF5_Fortran_RETURN_VALUE )
+set(HDF5_HL_COMPILE_LINE ${HDF5_C_COMPILE_LINE})
+set(HDF5_Fortran_HL_COMPILE_LINE ${HDF5_Fortran_COMPILE_LINE})
 
 # seed the initial lists of libraries to find with items we know we need
 set( HDF5_C_LIBRARY_NAMES_INIT hdf5 )
-- 
2.1.4

From 7e613004df9d107fbae34300d258385d229052cb Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Tue, 1 Sep 2015 09:20:25 +0700
Subject: [PATCH 2/3] FindHDF5: Add hdf5_hl to list of libraries to search for
 Fortran_HL

When the Fortran_HL component is specified, the hdf5_hl library is not included
in HDF5_LIBRARIES which causes a bunch of undefined references at link
time. This commit adds hdf5_hl to the list of libraries to search for when the
Fortran_HL component is specified.
---
 Modules/FindHDF5.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 47d85f7..a449132 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -234,7 +234,7 @@ if( NOT HDF5_FOUND )
 set( HDF5_CXX_LIBRARY_NAMES_INIT hdf5_cpp ${HDF5_C_LIBRARY_NAMES_INIT} )
 set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran
 ${HDF5_C_LIBRARY_NAMES_INIT} )
-set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran
+set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl
 ${HDF5_Fortran_LIBRARY_NAMES_INIT} )
 
 foreach( LANGUAGE ${HDF5_LANGUAGE_BINDINGS} )
-- 
2.1.4

From c35a7766ec7dc07adf54c0d5b504f07a9c35f3ab Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Tue, 1 Sep 2015 09:21:52 +0700
Subject: [PATCH 3/3] FindHDF5: Introduce HDF5_PREFER_PARALLEL option to
 address #15527

When a serial and parallel installation of HDF5 are installed alongside one
another, the serial version is always preferred due to the ordering of
h5cc/h5pcc in find_program. This commit introduces a variable
HDF5_PREFER_PARALLEL which swaps the order of the programs and therefore allows
a parallel HDF5 version to be found.
---
 Modules/FindHDF5.cmake | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index a449132..4e740c8 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -103,26 +103,37 @@ else()
 endforeach()
 endif()
 
+# Determine whether to search for serial or parallel executable first
+if(HDF5_PREFER_PARALLEL)
+  set(HDF5_C_COMPILER_NAMES h5pcc h5cc)
+  set(HDF5_CXX_COMPILER_NAMES h5pc++ h5c++)
+  set(HDF5_Fortran_COMPILER_NAMES h5pfc h5fc)
+else()
+  set(HDF5_C_COMPILER_NAMES h5cc h5pcc)
+  set(HDF5_CXX_COMPILER_NAMES h5c++ h5pc++)
+  set(HDF5_Fortran_COMPILER_NAMES h5fc h5pfc)

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

2015-08-31 Thread Mikhail Filimonov

Hi, guys.
It looks that an error ‘ld.bfd.exe: cannot find -l-Wl,-Bdynamic’
was introduced by
commit 675ef165f213a6db1f9d0dfbebf6a0afc5469494
Author: Chuck Atkins 
Date:   Fri Aug 7 15:11:57 2015 -0400
Allow LINK_SEARCH_{START,END}_STATIC props to have default values.
Use the CMAKE_LINK_SEARCH_START_STATIC and CMAKE_LINK_SEARCH_END_STATIC
variables to initialize the LINK_SEARCH_START_STATIC and
LINK_SEARCH_END_STATIC target properties respectively.
it seems that it uncovered the hidden error in linker flags command line 
generation.
I’ve attached a simple fix that mitigates the issue, though maybe Chuck could 
devise a better way to handle it.

Peter, you could apply the attached patch locally to the latest CMake source to 
verify if it helps.

Regards,
-Mikhail

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Dmitry Polyanitsa
Sent: Friday, August 28, 2015 7:32 PM
To: Peter List 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant 
Build) in cmake file

Hi Peter,

We’ll look into that and get back to you!

-Dmitry

From: Peter List [mailto:pem.l...@gmail.com]
Sent: Friday, August 28, 2015 8:45 AM
To: Dmitry Polyanitsa >
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant 
Build) in cmake file

A related but different issue...  I tried adding this to my CMakeLists.txt:

set(CMAKE_ANDROID_NATIVE_LIB_DEPENDENCIES zzz)
set(CMAKE_ANDROID_NATIVE_LIB_DIRECTORIES yyy)

But cmake 3.1.1 release does not add the expected properties to my vcxproj.  In 
fact, the strings "zzz" and "yyy" are not found in my vcxproj file.

So I tried a nightly build, but I got a different error - full text pasted below

Looks like cmake is doing some sanity check by building a simple test program, 
but link fails with cannot find -l-Wl,-Bdynamic.

Maybe "cmake-3.3.20150826-g566f1-win32-x86" isn't ready yet?

Btw I'm using AndroidWorks-1R2-win.exe + 
NVIDIA_Nsight_Tegra_Release_3.1.15202.6244.exe, so another guess is that maybe 
it's a compatibility issue...  Like I have to use a particular version of 
nsight with a particular version of cmake

thank you for any leads,
Peter

...
...
...

> "C:\Program Files (x86)\cmake-3.3.20150826-g566f1-win32-x86\bin\cmake" 
> -G"Visual Studio 10 2010" -DCMAKE_SYSTEM_NAME="Android"  ..\pemDemos

-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
-- Check for working C compiler using: Visual Studio 10 2010
-- Check for working C compiler using: Visual Studio 10 2010 -- broken
CMake Error at C:/Program Files 
(x86)/cmake-3.3.20150826-g566f1-win32-x86/share/cmake-3.3/Modules/CMakeTestCCompiler.cmake:61
 (message):
  The C compiler
  
"C:/Programs/NVPACK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe"
  is not able to compile a simple test program.
  It fails with the following output:
   Change Dir: 
H:/Pem_Code/grfxdemossdl2015/pemDemos/build-android-vs2010/CMakeFiles/CMakeTmp
  Run Build
  Command:"C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe"
  "cmTC_84fb1.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=10.0"
  Microsoft (R) Build Engine version 4.6.79.0
  [Microsoft .NET Framework, version 4.0.30319.42000]
  Copyright (C) Microsoft Corporation.  All rights reserved.
  Build started 8/28/2015 12:35:31 AM.

  Project
  
"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj"
  on node 1 (default targets).

  PrepareForBuild:

Creating directory "cmTC_84fb1.dir\Debug\".
Creating directory 
"H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\Debug\".

  InitializeBuildStatus:

Creating "cmTC_84fb1.dir\Debug\cmTC_84fb1.unsuccessfulbuild" because 
"AlwaysCreate" was specified.

  ClCompile:


C:\Programs\NVPACK\android-ndk-r10e\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe
testCCompiler.c

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(991,5): warning
  MSB8012: TargetExt(.) does not match the Linker's OutputFile property value
  ().  This may cause your project to build incorrectly.  To correct this,
  please make sure that $(OutDir), $(TargetName) and $(TargetExt) property
  values match the value specified in %(Link.OutputFile).
  
[H:\Pem_Code\grfxdemossdl2015\pemDemos\build-android-vs2010\CMakeFiles\CMakeTmp\cmTC_84fb1.vcxproj]


  Link:


C:\Programs\NVPACK\android-ndk-r10e\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe
 cmTC_84fb1.dir
Debug/testCCompiler.o  -Wl,-soname,cmTC_84fb1. -shared

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

2015-08-31 Thread Brad King

On 08/31/2015 11:16 AM, Mikhail Filimonov wrote:
> It looks that an error ‘ld.bfd.exe: cannot find -l-Wl,-Bdynamic’
> 
> was introduced by
> 
> commit 675ef165f213a6db1f9d0dfbebf6a0afc5469494

I discovered that problem in unrelated work last week and had prepared
a commit to revert it.  Chuck and I were debating what the proper
behavior is but for now we'll just revert the offending changes:

 Revert LINK_SEARCH_{START,END}_STATIC behavior change
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9e21b01a

-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] FindZLIB module should find debug and, release variants

2015-08-31 Thread Brad King

On 08/28/2015 05:37 PM, Michael Scott wrote:
> Okay, I've modified the patch to only add the DEBUG and RELEASE 
> configurations when the corresponding library is found, and not set the 
> generic IMPORTED_LOCATION property at all.

Thanks.  We also need to be compatible with projects or scripts that
set ZLIB_LIBRARY themselves.  See how FindTIFF did that here:

 FindTIFF: Find debug and release libraries separately
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=724fa682

Sorry I didn't notice this on the last review.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

2015-08-31 Thread Brad King

On 08/31/2015 04:47 AM, Paul Romano wrote:
> I'd like to offer the attached patch for consideration

Thanks for working on these changes.

Please split each independent fix out into its own commit with
corresponding commit message explaining the change.

For the HDF5_PREFER_PARALLEL implementation, please re-use
the existing find_program calls but simply prepare a variable
ahead of time that lists the preferred order of names.  OTOH,
there is another approach to solve this.  The find_library
command has a NAMES_PER_DIR option that says to consider all
the given names in each directory before moving on to the next
directory.  If find_program had this too then one would be able
to choose a preference simply by having one come first in PATH.

-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] CTest threshold exceeds 1024 bytes

2015-08-31 Thread Brad King

On 08/31/2015 07:36 AM, "Roman Wüger" wrote:
> Attached you will find the corrected patch.

Thanks.  I've attached a revised version.  I renamed the options
and added release notes.  I also started the test case.  Please
try completing the test and getting it to pass from there.

BTW, I noticed that there is actually a way to set these values
already.  It just is not documented.  Try this:

 $ git grep CTEST_CUSTOM_MAXIMUM_.*_TEST_OUTPUT_SIZE

to see the options.  They can be set in ctest scripts but not
on the command line.

-Brad

>From 4a1c6c75d20f3b9f4f6b40779322250ba9786d6f Mon Sep 17 00:00:00 2001
Message-Id: <4a1c6c75d20f3b9f4f6b40779322250ba9786d6f.1441048648.git.brad.k...@kitware.com>
From: =?UTF-8?q?Roman=20W=C3=BCger?= 
Date: Mon, 31 Aug 2015 11:19:23 +0200
Subject: [PATCH] CTest learned to limit the output of passed and failed tests

---
 Help/manual/ctest.1.rst|  6 
 Help/release/dev/ctest-custom-output-size.rst  |  7 
 Source/CTest/cmCTestTestHandler.h  |  5 +++
 Source/cmCTest.cxx | 41 +-
 Source/ctest.cxx   |  4 +++
 Tests/RunCMake/ctest_test/CMakeLists.txt.in|  1 +
 Tests/RunCMake/ctest_test/RunCMakeTest.cmake   | 11 ++
 .../RunCMake/ctest_test/TestOutputSize-check.cmake |  8 +
 8 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 Help/release/dev/ctest-custom-output-size.rst
 create mode 100644 Tests/RunCMake/ctest_test/TestOutputSize-check.cmake

diff --git a/Help/manual/ctest.1.rst b/Help/manual/ctest.1.rst
index 50c856a..2fdf7f3 100644
--- a/Help/manual/ctest.1.rst
+++ b/Help/manual/ctest.1.rst
@@ -302,6 +302,12 @@ Options
 ``--test-command``
  The test to run with the --build-and-test option.
 
+``--test-output-size-passed ``
+ Limit the output for passed tests to  bytes.
+
+``--test-output-size-failed ``
+ Limit the output for failed tests to  bytes.
+
 ``--test-timeout``
  The time limit in seconds, internal use only.
 
diff --git a/Help/release/dev/ctest-custom-output-size.rst b/Help/release/dev/ctest-custom-output-size.rst
new file mode 100644
index 000..8098b93
--- /dev/null
+++ b/Help/release/dev/ctest-custom-output-size.rst
@@ -0,0 +1,7 @@
+ctest-custom-output-size
+
+
+* :manual:`ctest(1)` learned options
+  ``--test-output-size-passed`` and ``--test-output-size-failed``
+  to customize the limit on test output size submitted when
+  running as a :ref:`Dashboard Client`.
diff --git a/Source/CTest/cmCTestTestHandler.h b/Source/CTest/cmCTestTestHandler.h
index 14067d5..c635430 100644
--- a/Source/CTest/cmCTestTestHandler.h
+++ b/Source/CTest/cmCTestTestHandler.h
@@ -65,6 +65,11 @@ public:
   void SetMaxIndex(int n) {this->MaxIndex = n;}
   int GetMaxIndex() {return this->MaxIndex;}
 
+  void SetTestOutputSizePassed(int n)
+{ this->CustomMaximumPassedTestOutputSize = n; }
+  void SetTestOutputSizeFailed(int n)
+{ this->CustomMaximumFailedTestOutputSize = n; }
+
   ///! pass the -I argument down
   void SetTestsToRunInformation(const char*);
 
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index b2ad4a8..6e55d89 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -2165,7 +2165,46 @@ bool cmCTest::HandleCommandLineArguments(size_t ,
 {
 this->OutputTestOutputOnTestFailure = true;
 }
-
+  if (this->CheckArgument(arg, "--test-output-size-passed") &&
+  i < args.size() - 1)
+{
+i++;
+long outputSize;
+if (cmSystemTools::StringToLong(args[i].c_str(), ))
+  {
+  if (cmCTestTestHandler *pCTestTestHandler =
+  static_cast(this->TestingHandlers["test"]))
+{
+pCTestTestHandler->SetTestOutputSizePassed(int(outputSize));
+}
+  }
+else
+  {
+  cmCTestLog(this, WARNING,
+ "Invalid value for '--test-output-size-passed': " <<
+ args[i] << "\n");
+  }
+}
+  if (this->CheckArgument(arg, "--test-output-size-failed") &&
+  i < args.size() - 1)
+{
+i++;
+long outputSize;
+if (cmSystemTools::StringToLong(args[i].c_str(), ))
+  {
+  if (cmCTestTestHandler *pCTestTestHandler =
+  static_cast(this->TestingHandlers["test"]))
+{
+pCTestTestHandler->SetTestOutputSizeFailed(int(outputSize));
+}
+  }
+else
+  {
+  cmCTestLog(this, WARNING,
+ "Invalid value for '--test-output-size-failed': " <<
+ args[i] << "\n");
+  }
+}
   if(this->CheckArgument(arg, "-N", "--show-only"))
 {
 this->ShowOnly = true;
diff --git a/Source/ctest.cxx b/Source/ctest.cxx
index afcbd61..7fa6aed 100644
--- a/Source/ctest.cxx
+++ b/Source/ctest.cxx
@@ -46,6 +46,10 @@ static const char * cmDocumentationOptions[][2] =
   {"--debug", "Displaying more verbose internals of CTest."},
   {"--output-on-failure",

Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)

2015-08-31 Thread Brad King

On 08/31/2015 09:35 AM, Kislinskiy, Stefan wrote:
> As there is already a patch for such a genex in bug 15509 and the
> discussion in 5939 (both linked below in Brad's reply) started 7
> years ago... It would be a great pity to let this issue seep away
> again. What can I do to help fixing this finally?

Someone will need to think through and propose a specific genex that
does the path conversion that makes sense in this context.  I think
something like $ may be appropriate.

For referencing command line tools (as argv[0]) the C++ side uses
code like this now:

 this->ConvertToOutputFormat(ccg.GetCommand(i), SHELL)

This genex should map to the same conversion internally.

-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] New policy to address rdynamic

2015-08-31 Thread Chuck Atkins

So, from what I can tell, the Visual Studio generator and Xcode generator
don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS.  I know it's the
generators and not platforms since my tests pass on these platforms with
Makefile and Ninja generators but fail with Visual Studio and Xcode
generators.  Is this common to all multi-config generators or just these
two? I'm trying to determine under which circumstances the policy is even
applicable.

- Chuck

On Wed, Aug 26, 2015 at 6:30 PM, Chuck Atkins 
wrote:

> Maybe
>>
>>  [TARGET_PROPERTIES   [ ]... ]
>>
>> makes sense instead?
>>
>> That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.
>>
>
> Good idea!  I actually do like that better, but it's outside the scope of
> this change.  For now I'll remove the ENABLE_EXPORTS but still propagate
> the policy and then push a separate branch to add the TARGET_PROPERTIES
> argument.
>
> Thanks
> - Chuck
>
-- 

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] New policy to address rdynamic

2015-08-31 Thread Brad King

On 08/31/2015 03:44 PM, Chuck Atkins wrote:
> the Visual Studio generator and Xcode generator
> don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS

This is likely true and has not been noticed because the
Platform modules do not set any value for this variable
on any platform supported by those generators.  Those
generators could be fixed and it would not change anything
for existing platforms.

-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 0015722]: ExternalProject.cmake calls 'git stash save --all' even if git doesn't support --all option

2015-08-31 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15722 
== 
Reported By:Kevin Godby
Assigned To:
== 
Project:CMake
Issue ID:   15722
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-08-31 15:49 EDT
Last Modified:  2015-08-31 15:49 EDT
== 
Summary:ExternalProject.cmake calls 'git stash save --all'
even if git doesn't support --all option
Description: 
The --all option for git-stash wasn't introduced until git version 1.7.6. If you
use ExternalProject_Add with a git repository and have an old version of git
installed, cmake will fail when it tries to call 'git stash save --all --quiet'.

Steps to Reproduce: 
* Install a old version of git (<= 1.7.5).
* Use recent version of cmake.
* Try to download a git repository using ExternalProject_Add.


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-31 15:49 Kevin GodbyNew Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Patch] Adding Windows 10 support

2015-08-31 Thread Brad King

On 08/30/2015 06:41 PM, Gilles Khouzam wrote:
> http://www.cmake.org/Bug/view.php?id=15670
> Add support for setting "Windows target platform version" in VS2015

Most of your changes look good but I think this issue needs more
discussion.  There is already some discussion in the issue tracker
entry linked above.

Your patch checks a VS_DEFAULT_TARGET_PLATFORM_VERSION variable
but does not document it or explain who/what is supposed to set
it.  There is a comment about using the latest SDK but right now
it looks like the value of that variable is used directly.

Having a VS_TARGET_PLATFORM_VERSION target property is convenient
for customization but should not be the main way to set this value.
The WindowsTargetPlatformVersion value is something that should
be set in try_compile projects too for consistency.  If we were
only cross-compiling then having a toolchain file setting would
make sense.  However, this should work when not cross-compiling
too.

On OS X we have CMAKE_OSX_SYSROOT to specify the SDK.  The value is
propagated by Source/cmCoreTryCompile.cxx into try_compile projects.
It is selected originally by Modules/Platform/Darwin-Initialize.cmake
if not specified by the user.  I think similar infrastructure should
be built for selecting the Windows SDK.

> As part of this change, I’m also fixing a bug when using VS2015 to
> target Windows Phone or Windows Store 8.1 without having VS2013
[snip]
> simply to make the desktop detection code be virtual.

Please split the relevant hunks for that part out so they can be
committed with their own message/explanation.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Happy Birthday CMake!

2015-08-31 Thread Bill Hoffman


Today is the 15th birthday of CMake:

http://www.kitware.com/blog/home/post/959

Thanks to everyone that has used and contributed to CMake over the years!

-Bill
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

2015-08-31 Thread Raphael Kubo da Costa

Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries")
introduced a few new ExportImport tests, and the
check_lib_{no}soname.cmake scripts that parse readelf(1)'s output.

Make the regular expression matching the SONAME line output by readelf
less strict, as the output format varies across implementations: GNU
binutils' readelf is the only one to write each ELF header within
parentheses (which the previous regular expression expected). The new
tests were thus failing when either Fedora's elfutils (eu-readelf) or
elftoolchain's readelf (present on recent FreeBSD versions) were being
used, as they both list the headers without parentheses.
---
 Tests/ExportImport/Import/A/check_lib_nosoname.cmake | 2 +-
 Tests/ExportImport/Import/A/check_lib_soname.cmake   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Tests/ExportImport/Import/A/check_lib_nosoname.cmake 
b/Tests/ExportImport/Import/A/check_lib_nosoname.cmake
index 6261ff4..613391e 100644
--- a/Tests/ExportImport/Import/A/check_lib_nosoname.cmake
+++ b/Tests/ExportImport/Import/A/check_lib_nosoname.cmake
@@ -1,5 +1,5 @@
 execute_process(COMMAND ${readelf} -d ${lib} OUTPUT_FILE ${lib}.readelf.txt)
-file(STRINGS ${lib}.readelf.txt soname REGEX "\\(SONAME\\)")
+file(STRINGS ${lib}.readelf.txt soname REGEX "SONAME")
 if(soname)
   message(FATAL_ERROR "${lib} has soname but should not:\n  ${soname}")
 else()
diff --git a/Tests/ExportImport/Import/A/check_lib_soname.cmake 
b/Tests/ExportImport/Import/A/check_lib_soname.cmake
index 7794e80..a3c4b54 100644
--- a/Tests/ExportImport/Import/A/check_lib_soname.cmake
+++ b/Tests/ExportImport/Import/A/check_lib_soname.cmake
@@ -1,5 +1,5 @@
 execute_process(COMMAND ${readelf} -d ${lib} OUTPUT_FILE ${lib}.readelf.txt)
-file(STRINGS ${lib}.readelf.txt soname REGEX "\\(SONAME\\)")
+file(STRINGS ${lib}.readelf.txt soname REGEX "SONAME")
 if(soname)
   message(STATUS "${lib} has soname as expected:\n  ${soname}")
 else()
-- 
2.4.6

-- 

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] CTest threshold exceeds 1024 bytes

2015-08-31 Thread Roman Wüger

Hi Brad,

sorry for the long response time, but I was on vacation.

Attached you will find the corrected patch.

Best regards
Roman



Am 20.08.15 um 17:30 schrieb Brad King

> On 08/20/2015 06:30 AM, Roman Wüger wrote:
> 
> > I made the "atoi" change but my problem is the test itself.
> 
> > I don't know how to specify the command line parameter and
> 
> > check the generated xml file.
> 
> 
> 
> Okay, please post the latest version of the patch so far and
> 
> I'll see if I can find a chance to work on the test.
> 
> 
> 
> Thanks,
> 
> -Brad


0001-ctest-learned-to-limit-the-output-of-passed-and-fail.patch
Description: Binary data
-- 

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 a few issues in FindHDF5 module

2015-08-31 Thread Paul Romano

I'd like to offer the attached patch for consideration that fixes a number
of issues with FindHDF5.cmake. The issues are as follows:

1. Searching for libraries related to the HL and Fortran_HL components is a
bit broken at the moment; for example, if you specify the Fortran_HL
component, HDF5_INCLUDE_DIRS ends up including
HDF5_Fortran_HL_INCLUDE_DIR-NOTFOUND, which makes HDF5_INCLUDE_DIRS
evaluate to false, thus causing the overall find_package to fail. The
debian maintainers actually have included a two-line patch to fix this
going all the way back to pre-3.0 for their cmake-data package. That patch
is included here.

2. Even with the aforementioned patch, specifying the Fortran_HL component
doesn't include the hdf5_hl library, which results in a bunch of undefined
references at link time. I've added that library to the list of libraries
to be searched for Fortran_HL.

3. In issue #15527, it is reported that when a serial and parallel
installation of HDF5 are installed alongside one another, the serial
version is always preferred even if you specify the parallel version in
HDF5_ROOT. This is a result of find_program searching for h5cc and h5pcc
simulataneously, with h5cc listed first. In the attached patch, one can now
set the HDF5_PREFER_PARALLEL variable which tells FindHDF5 to search for
h5pcc first rather than h5cc.

Best regards,
Paul
From 883a9f93c892a5580369adba542c2f852332ff41 Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Mon, 31 Aug 2015 10:11:44 +0700
Subject: [PATCH] FindHDF5: Fix HL compile line and add means of preferring
 parallel

The debian cmake-data package currently includes a patch that finds the correct
include directories and libraries when the HL or Fortran_HL components are
specified. This commit brings that patch upstream. Additionally, the
HDF5_PREFER_PARALLEL variable is introduced to resolve issue 0015527 whereby
there is no way to find a parallel HDF5 installation if both h5cc and h5pcc
appear on the user's PATH. Finally, when the Fortran_HL component is specified,
the hdf5_hl library is searched for.
---
 Modules/FindHDF5.cmake | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 3bd6f1e..ec8b4a1 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -104,26 +104,49 @@ else()
 endif()
 
 # try to find the HDF5 wrapper compilers
-find_program( HDF5_C_COMPILER_EXECUTABLE
+if(HDF5_PREFER_PARALLEL)
+  find_program( HDF5_C_COMPILER_EXECUTABLE
+NAMES h5pcc h5cc
+HINTS ENV HDF5_ROOT
+PATH_SUFFIXES bin Bin
+DOC "HDF5 Wrapper compiler.  Used only to detect HDF5 compile flags." )
+  mark_as_advanced( HDF5_C_COMPILER_EXECUTABLE )
+
+  find_program( HDF5_CXX_COMPILER_EXECUTABLE
+NAMES h5pc++ h5c++
+HINTS ENV HDF5_ROOT
+PATH_SUFFIXES bin Bin
+DOC "HDF5 C++ Wrapper compiler.  Used only to detect HDF5 compile flags." )
+  mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
+
+  find_program( HDF5_Fortran_COMPILER_EXECUTABLE
+NAMES h5pfc h5fc
+HINTS ENV HDF5_ROOT
+PATH_SUFFIXES bin Bin
+DOC "HDF5 Fortran Wrapper compiler.  Used only to detect HDF5 compile flags." )
+  mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
+else()
+  find_program( HDF5_C_COMPILER_EXECUTABLE
 NAMES h5cc h5pcc
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 Wrapper compiler.  Used only to detect HDF5 compile flags." )
-mark_as_advanced( HDF5_C_COMPILER_EXECUTABLE )
+  mark_as_advanced( HDF5_C_COMPILER_EXECUTABLE )
 
-find_program( HDF5_CXX_COMPILER_EXECUTABLE
+  find_program( HDF5_CXX_COMPILER_EXECUTABLE
 NAMES h5c++ h5pc++
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 C++ Wrapper compiler.  Used only to detect HDF5 compile flags." )
-mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
+  mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
 
-find_program( HDF5_Fortran_COMPILER_EXECUTABLE
+  find_program( HDF5_Fortran_COMPILER_EXECUTABLE
 NAMES h5fc h5pfc
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 Fortran Wrapper compiler.  Used only to detect HDF5 compile flags." )
-mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
+  mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
+endif()
 
 find_program( HDF5_DIFF_EXECUTABLE
 NAMES h5diff
@@ -225,6 +248,8 @@ if( NOT HDF5_FOUND )
 _HDF5_invoke_compiler( C HDF5_C_COMPILE_LINE HDF5_C_RETURN_VALUE )
 _HDF5_invoke_compiler( CXX HDF5_CXX_COMPILE_LINE HDF5_CXX_RETURN_VALUE )
 _HDF5_invoke_compiler( Fortran HDF5_Fortran_COMPILE_LINE HDF5_Fortran_RETURN_VALUE )
+set(HDF5_HL_COMPILE_LINE ${HDF5_C_COMPILE_LINE})
+set(HDF5_Fortran_HL_COMPILE_LINE ${HDF5_Fortran_COMPILE_LINE})
 
 # seed the initial lists of libraries to find with items we know we need
 set( HDF5_C_LIBRARY_NAMES_INIT hdf5 )
@@ -232,7 +257,7 @@ if( NOT HDF5_FOUND )
 set( HDF5_CXX_LIBRARY_NAMES_INIT hdf5_cpp

[cmake-developers] refactor-progress topic regressed Makefile progress

2015-08-31 Thread Brad King

Steve,

The topic merged here:

 Merge topic 'refactor-progress'
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2985b9c0

sometimes breaks "make" progress.  So far I've only been able to
reproduce this when building CMake itself.  In an up-to-date build
tree I get output like:

 $ make
 ...
 Built target ccmake
 Built target cmake
 Built target cpack
 Built target ctest
 Built target cmake-gui
 ...

During the actual build I get no progress output either.
The problem bisects to:

 cmGlobalUnixMakefileGenerator3: Implement progress in terms of cmState.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fbc56ac

Please take a look.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015721]: Indexer configuration of Eclipse CDT4 Project does not recognize symbols set by modules

2015-08-31 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15721 
== 
Reported By:Thomas Ruschival
Assigned To:
== 
Project:CMake
Issue ID:   15721
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-08-31 09:23 EDT
Last Modified:  2015-08-31 09:23 EDT
== 
Summary:Indexer configuration of Eclipse CDT4 Project does
not recognize symbols set by modules
Description: 
The issue is a minor one regarding the macros ( symbol definitions) for the
eclipse CDT indexer. 
The cmake-generated eclipse project only recognizes symbols that are explicitly
added with add_defintions() in CMakeLists.txt. The eclipse project does not
consider any target-specific COMPILE_DEFINITIONS for indexing the source.

Also a list of compile defintions defined by a module that can be used in target
compile defintions cannot be used with add_definitions().   

Currently I mitigate this behavior by 
find_package(FOO REQUIRED) # FOO defines a list FOO_COMPILE_DEFINITIONS

# This does not work since each symbol has to start with -D
# ADD_DEFINITIONS(${FOO_COMPILE_DEFINITIONS})

foreach( DEF ${FOO_COMPILE_DEFINITIONS})
   ADD_DEFINITIONS("-D${DEF}")
endforeach(DEF)

IMHO this is somewhat ugly. I would prefer to have all definitions used for the
targets added to the indexer settings of eclipse to allow for easy source
navigation. Since the project is build by makefiles anyway adding all symbols
doesn't affect the build.

Does this make sense or am I looking in the wrong direction?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-08-31 09:23 Thomas RuschivalNew Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

2015-08-31 Thread Kislinskiy, Stefan

As there is already a patch for such a genex in bug 15509 and the discussion in 
5939 (both linked below in Brad's reply) started 7 years ago... It would be a 
great pity to let this issue seep away again. What can I do to help fixing this 
finally?

Stefan 

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
CHEVRIER, Marc
Sent: Freitag, 28. August 2015 10:07
To: Brad King; cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

Offering generator-expressions is a very good idea because it offers a global 
solution to this problem.

Now regarding the name of the generator, may be TO_NATIVE_PATH is not 
judicious, (even if problems explained in 
http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to 
platforms not well handled rather than wrong semantic of TO_NATIVE_PATH) but 
PATH_FOR_SHELL is, as well, ambiguous at least for two reasons:
* commands defined in add_custom_command, for example, are directly executed 
without any shell evolved
* A system can have multiple shells supporting different paths syntax. For 
example, on windows, my shell is tcsh which handle paths with ‘/‘ rather than 
‘\'

May be, TO_SYSTEM_PATH or TO_HOST_SYSTEM_PATH make more sense…

Marc

On 27/08/15 17:18, "cmake-developers on behalf of Brad King" 
 wrote:

>On 08/27/2015 10:06 AM, James Johnston wrote:
>> I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for 
>> consistency with the existing parameter in the file command.
>
>The file(TO_NATIVE_PATH) command is hopelessly ill-defined:
>
> http://www.cmake.org/Bug/view.php?id=5939
>
>See also existing discussion about a genex for such conversions:
>
> http://www.cmake.org/Bug/view.php?id=15509
>
>-Brad
>
>--
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

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] Add a test for checking that the CPack module produces correct config files

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

Re: [cmake-developers] nvidia nsight tegra set vcxproj properties (Ant Build) in cmake file

Re: [cmake-developers] FindZLIB module should find debug and, release variants

Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

Re: [cmake-developers] CTest threshold exceeds 1024 bytes

Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)

Re: [cmake-developers] New policy to address rdynamic

Re: [cmake-developers] New policy to address rdynamic

[cmake-developers] [CMake 0015722]: ExternalProject.cmake calls 'git stash save --all' even if git doesn't support --all option

Re: [cmake-developers] [Patch] Adding Windows 10 support

[cmake-developers] Happy Birthday CMake!

[cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME".

Re: [cmake-developers] CTest threshold exceeds 1024 bytes

[cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

[cmake-developers] refactor-progress topic regressed Makefile progress

[cmake-developers] [CMake 0015721]: Indexer configuration of Eclipse CDT4 Project does not recognize symbols set by modules

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

19 matches

Site Navigation

Mail list logo

Footer information