date:20150903

[cmake-developers] [CMake 0015725]: post generate action

2015-09-03 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15725 
== 
Reported By:Gregory Kramida
Assigned To:
== 
Project:CMake
Issue ID:   15725
Category:   CMake
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-03 12:11 EDT
Last Modified:  2015-09-03 12:11 EDT
== 
Summary:post generate action
Description: 
It would be great if users had the ability to schedule processes after the
generation step.

There are many ways, i.e. adding another command, but I guess the easiest way to
achieve that would be by extending the execute_process command with something
like a SCHEDULE_AFTER_GENERATION flag.

Additional Information: 
See http://www.cmake.org/pipermail/cmake/2010-May/037151.html
See comments in answer here
http://stackoverflow.com/questions/7091447/run-command-after-generation-step-in-cmake

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-03 12:11 Gregory KramidaNew 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-09-03 Thread Gilles Khouzam

Sorry, you are right, try_compile calls do use the generator and don't have a 
problem. 

I was trying to do something similar to what you are describing here:
> We could simply define a
> 
>  CMAKE_VS_TARGET_PLATFORM_VERSION
> 
> variable that is used to initialize VS_TARGET_PLATFORM_VERSION target 
> properties (see SetPropertyDefault calls in the source).
> Then the generator can look just at the target property.  If not set it 
> should choose a default based on the current host version of Windows as 
> discussed above.  Then we just need to teach cmCoreTryCompile to propagate 
> this
> setting.
> 
> The above-linked issue also mentions that TargetFrameworkVersion may need 
> similar infrastructure.

Perhaps the default selection (at least for Store apps since that's the one 
that requires the flag) should be the newest SDK less than the version of the 
host System. If CMAKE_VS_TARGET_PLATFORM_VERSION is specified then we would 
simply use it.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 2, 2015 08:25
To: Gilles Khouzam 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/01/2015 05:19 PM, Gilles Khouzam wrote:
> For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is 
> almost an internal property that is used for the try_compile phase. 
> Since the generator is not used in that scenario, the project is using 
> the template from Modules/CompilerId/VS-10.vcxproj.in. In that case, 
> we need to set the tag for the WindowsTargetPlatformVersion. During 
> the generation, I query for the latest SDK version in the 
> GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION
> property that is then used in CMakeDetermineCompilerId.cmake to set 
> the variable that the template uses in the Windows 10 case.

The generator *is* used for try_compile calls.  The template in 
Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler 
identification step which occurs before we have enough information to do a full 
try_compile.  The compiler id step does need special handling to set this 
value, but it should be based on however the value is determined for the 
generator normally.

As discussed in http://www.cmake.org/Bug/view.php?id=15670
the SDK for the latest Windows version may not be the proper default choice.  
Perhaps it should be the SDK for the host machine's version of Windows to make 
sure we don't use APIs that cannot run on the current machine.  IIRC this is 
the default on OS X with CMAKE_OSX_SYSROOT.

Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the 
WindowsTargetPlatformVersion value is something only for the VS IDE generators. 
 In any command-line build we expect the INCLUDE/LIB environment variables to 
already be set to the proper location.  Therefore we need to define a way to 
set the WindowsTargetPlatformVersion only for VS IDE generators since they 
generate the environment in which to run the toolchain.

CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with 
generator-specific behavior.  For VS they set  and , 
respectively.
There is quite a bit of C++-side infrastructure to propagate these values to 
all the right places (and honor cmake -T and -A options on the command line).  
I'd rather not have something quite so heavyweight for 
WindowsTargetPlatformVersion because it is a pretty narrow case that should not 
need a dedicated command-line option and won't be meaningful to other 
generators.

We could simply define a

 CMAKE_VS_TARGET_PLATFORM_VERSION

variable that is used to initialize VS_TARGET_PLATFORM_VERSION target 
properties (see SetPropertyDefault calls in the source).
Then the generator can look just at the target property.  If not set it should 
choose a default based on the current host version of Windows as discussed 
above.  Then we just need to teach cmCoreTryCompile to propagate this setting.

The above-linked issue also mentions that TargetFrameworkVersion may need 
similar infrastructure.

-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] [PATCH] CPack: don't mangle CMake-special characters when applying default settings

2015-09-03 Thread Роман Донченко

By using a function to do it instead of a macro. Deprecate the old macro,
but keep it for backwards compatibility. Remove existing workarounds for this
problem and add a test.
---
 Help/release/dev/CPack-updates.rst |  6 ++
 Modules/CPack.cmake| 92 ++
 Tests/RunCMake/CPackConfig/Default-check.cmake |  7 ++
 Tests/RunCMake/CPackConfig/Default.cmake   |  3 +
 Tests/RunCMake/CPackConfig/RunCMakeTest.cmake  |  1 +
 Tests/RunCMake/CPackConfig/check.cmake |  4 ++
 6 files changed, 70 insertions(+), 43 deletions(-)
 create mode 100644 Help/release/dev/CPack-updates.rst
 create mode 100644 Tests/RunCMake/CPackConfig/Default-check.cmake
 create mode 100644 Tests/RunCMake/CPackConfig/Default.cmake

diff --git a/Help/release/dev/CPack-updates.rst 
b/Help/release/dev/CPack-updates.rst
new file mode 100644
index 000..7ac1ed7
--- /dev/null
+++ b/Help/release/dev/CPack-updates.rst
@@ -0,0 +1,6 @@
+CPack-updates
+-
+
+* The :module:`CPack` module no longer mangles settings with CMake-special
+  characters when they're used as defaults for other settings. The macro
+  ``cpack_set_if_not_set``, which was responsible for this, is now deprecated.
diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index e223286..9fe349c 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -299,10 +299,10 @@ endif()
 include(CPackComponent)
 
 # Macro for setting values if a user did not overwrite them
+# Mangles CMake-special characters. Only kept for backwards compatibility.
 macro(cpack_set_if_not_set name value)
-  if(NOT DEFINED "${name}")
-set(${name} "${value}")
-  endif()
+  message(DEPRECATION "cpack_set_if_not_set is obsolete; do not use.")
+  _cpack_set_default("${name}" "${value}")
 endmacro()
 
 # cpack_encode_variables - Macro to encode variables for the configuration file
@@ -321,27 +321,35 @@ macro(cpack_encode_variables)
   endforeach()
 endmacro()
 
+# Internal use functions
+
+function(_cpack_set_default name value)
+  if(NOT DEFINED "${name}")
+set("${name}" "${value}" PARENT_SCOPE)
+  endif()
+endfunction()
+
 # Set the package name
-cpack_set_if_not_set(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}")
-cpack_set_if_not_set(CPACK_PACKAGE_VERSION_MAJOR "0")
-cpack_set_if_not_set(CPACK_PACKAGE_VERSION_MINOR "1")
-cpack_set_if_not_set(CPACK_PACKAGE_VERSION_PATCH "1")
-cpack_set_if_not_set(CPACK_PACKAGE_VERSION
+_cpack_set_default(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}")
+_cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR "0")
+_cpack_set_default(CPACK_PACKAGE_VERSION_MINOR "1")
+_cpack_set_default(CPACK_PACKAGE_VERSION_PATCH "1")
+_cpack_set_default(CPACK_PACKAGE_VERSION
   
"${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
-cpack_set_if_not_set(CPACK_PACKAGE_VENDOR "Humanity")
-cpack_set_if_not_set(CPACK_PACKAGE_DESCRIPTION_SUMMARY
+_cpack_set_default(CPACK_PACKAGE_VENDOR "Humanity")
+_cpack_set_default(CPACK_PACKAGE_DESCRIPTION_SUMMARY
   "${CMAKE_PROJECT_NAME} built using CMake")
 
-cpack_set_if_not_set(CPACK_PACKAGE_DESCRIPTION_FILE
+_cpack_set_default(CPACK_PACKAGE_DESCRIPTION_FILE
   "${CMAKE_ROOT}/Templates/CPack.GenericDescription.txt")
-cpack_set_if_not_set(CPACK_RESOURCE_FILE_LICENSE
+_cpack_set_default(CPACK_RESOURCE_FILE_LICENSE
   "${CMAKE_ROOT}/Templates/CPack.GenericLicense.txt")
-cpack_set_if_not_set(CPACK_RESOURCE_FILE_README
+_cpack_set_default(CPACK_RESOURCE_FILE_README
   "${CMAKE_ROOT}/Templates/CPack.GenericDescription.txt")
-cpack_set_if_not_set(CPACK_RESOURCE_FILE_WELCOME
+_cpack_set_default(CPACK_RESOURCE_FILE_WELCOME
   "${CMAKE_ROOT}/Templates/CPack.GenericWelcome.txt")
 
-cpack_set_if_not_set(CPACK_MODULE_PATH "${CMAKE_MODULE_PATH}")
+_cpack_set_default(CPACK_MODULE_PATH "${CMAKE_MODULE_PATH}")
 
 if(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL)
   set(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL ON)
@@ -359,7 +367,7 @@ if(__cpack_system_name MATCHES "Windows")
 set(__cpack_system_name win32)
   endif()
 endif()
-cpack_set_if_not_set(CPACK_SYSTEM_NAME "${__cpack_system_name}")
+_cpack_set_default(CPACK_SYSTEM_NAME "${__cpack_system_name}")
 
 # Root dir: default value should be the string literal "$PROGRAMFILES"
 # for backwards compatibility. Projects may set this value to anything.
@@ -369,17 +377,17 @@ if("x${__cpack_system_name}" STREQUAL "xwin64")
 else()
   set(__cpack_root_default "$PROGRAMFILES")
 endif()
-cpack_set_if_not_set(CPACK_NSIS_INSTALL_ROOT "${__cpack_root_default}")
+_cpack_set_default(CPACK_NSIS_INSTALL_ROOT "${__cpack_root_default}")
 
 # -..--.
-cpack_set_if_not_set(CPACK_PACKAGE_FILE_NAME
+_cpack_set_default(CPACK_PACKAGE_FILE_NAME
   "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}")
-cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_DIRECTORY
+_cpack_set_default(CPACK_PACKAGE_INSTALL_DIRECTORY
   "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}")
-cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

2015-09-03 Thread CHEVRIER, Marc


Hi,

Attached is a minimal example.
To use it:
1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to prepare 
runtime part
2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to show the 
bug.

Here is the result on my SuSE Linux with CMake 3.3.1 (binaries retrieved from 
CMake web site):

-- The C compiler identification is GNU 4.3.4
-- The CXX compiler identification is GNU 4.3.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Test1: Fail to found correct exe: 
/home/marc/tests/find_program.BUG/runtime/dir2/exe
Test2: Found correct exe: /home/marc/tests/find_program.BUG/runtime/dir1/exe
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marc/tests/find_program.BUG/runtime/gen

Marc





On 02/09/15 17:44, "Brad King"  wrote:

>On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote:
>> On 02/09/15 14:58, "Brad King" wrote:
>>> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote:
 find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3)
>>>
>>> find_program (MY_EXE
>>>   NAMES my_exe
>>>   HINTS PATH1 PATH2 PATH3
>>>   )
>> Same problem. HINTS which are also defined in the environment
>> variable PATH are ignored.
>
>I'm having trouble reproducing this.  Please provide a tarball
>with a full CMakeLists.txt and supporting files that demonstrate
>this.  You can "set(ENV{PATH} ...)" if needed.
>
>Thanks,
>-Brad


find_program.BUG.tar.gz
Description: find_program.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] [PATCH] Fix a few issues in FindHDF5 module

2015-09-03 Thread Paul Romano

Tim- I did notice your issue about Fortran HL not working but wasn't sure
what the original problem was or if it was still relevant. Anyway, I'm glad
we got a fix in, albeit four years later -- better late than never!

Brad- here's a new patch based off of 8ea7611 that uses the new
NAMES_PER_DIR option of find_program as well adds the HDF5_PREFER_PARALLEL
variable. The only case I know of where h5cc and h5pcc would get into the
same directory is in /usr/bin, e.g. the hdf5-helpers and
libhdf5-openmpi-dev packages in debian. However, the packagers don't use
the name h5pcc but rather h5pcc.mpich and h5pcc.openmpi, so in that case
HDF5_PREFER_PARALLEL doesn't actually help. Anyway, I'm going to cogitate
on the best way to handle that and may return with one more patch to handle
this situation.

Best,
Paul

On Wed, Sep 2, 2015 at 10:38 PM, Brad King  wrote:

> On 09/02/2015 11:35 AM, Tim Gallagher wrote:
> > it looks like this work supersedes that patch.
>
> Okay, thanks for checking!
>
> -Brad
>
>
From 636a9a244c508ad840dc8f78230171307d3e6e89 Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Thu, 3 Sep 2015 15:29:51 +0700
Subject: [PATCH] FindHDF5: Add NAMES_PER_DIR and introduce
 HDF5_PREFER_PARALLEL

The calls to find_program now use NAMES_PER_DIR so that the first executable
(e.g. h5pcc) appearing on their PATH will get chosen. The HDF5_PREFER_PARALLEL
variable swaps the search order when it is set to true in the event that a
directory being search contains both h5cc and h5pcc.
---
 Modules/FindHDF5.cmake | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index a449132..ea8526d 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -103,23 +103,34 @@ 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)
+endif()
+
 # try to find the HDF5 wrapper compilers
 find_program( HDF5_C_COMPILER_EXECUTABLE
-NAMES h5cc h5pcc
+NAMES ${HDF5_C_COMPILER_NAMES} NAMES_PER_DIR
 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 h5c++ h5pc++
+NAMES ${HDF5_CXX_COMPILER_NAMES} NAMES_PER_DIR
 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 h5fc h5pfc
+NAMES ${HDF5_Fortran_COMPILER_NAMES} NAMES_PER_DIR
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 Fortran Wrapper compiler.  Used only to detect HDF5 compile flags." )
@@ -378,4 +389,3 @@ find_package_handle_standard_args( HDF5
 REQUIRED_VARS HDF5_LIBRARIES HDF5_INCLUDE_DIRS
 VERSION_VAR   HDF5_VERSION
 )
-
-- 
2.1.4

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015725]: post generate action

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

[cmake-developers] [PATCH] CPack: don't mangle CMake-special characters when applying default settings

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

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

5 matches

Site Navigation

Mail list logo

Footer information