[Cmake-commits] CMake branch, master, updated. v3.8.0-1007-g7382523

[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  7382523f85ff365d18908eb906cd5502443df3b5 (commit)
  from  e3858dd50b521d1abf466ac5bc55e70a3fdcc5db (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=7382523f85ff365d18908eb906cd5502443df3b5
commit 7382523f85ff365d18908eb906cd5502443df3b5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sun Apr 30 00:01:03 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sun Apr 30 00:01:03 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b789dc0..5d1aa36 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 8)
-set(CMake_VERSION_PATCH 20170429)
+set(CMake_VERSION_PATCH 20170430)
 #set(CMake_VERSION_RC 1)

---

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


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

[cmake-developers] Issues with overriding Python version, possible bug?

[Alan W. Irwin]

My use case (which I am pretty sure is a common one) is that for
PLplot I want the default behaviour of our build system to be that it
looks for Python 3, but if that does not exist it looks for Python 2.

It appears the following logic implements that desired default
behaviour.

find_package(PythonInterp 3)
find_package(PythonInterp 2)

So far so good, but I am sure there will be some of our users that
prefer Python 2 even when Python 3 is installed on their system.

I could implement that user choice with a special FORCE_PYTHON2 option
option to allow the user to skip the first find_package command above,
but if possible I would far prefer that our users used a more standard
way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the
Python version they prefer. However, when I tried (for both CMake-3.6.2 and
CMake-3.8.0-rc4) -DPython_ADDITIONAL_VERSIONS:STRING=2, the result was
that setting was ignored, i.e., the result of the above two
find_package commands was

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "2")


Is this ignoring of Python_ADDITIONAL_VERSIONS for the above
find_package logic due to a bug in Modules/FindPythonInterp.cmake? Is
there some other standard way that the Python version can overridden
by the user for the above find_package logic?

(I am sorry I cannot answer either of these questions myself, but I am
having real trouble following the PythonInterp module logic for the
case when the default behaviour is specified via the above
find_package logic.)

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] DLL handling under CMake

[Hendrik Sattler]

Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
:
>This steps are tedious and I'm wondering if there is a mechanism that 
>exists or that have to be imagined to make the DLL nightmare end.

I use BundleUtilities to achieve the copying of DLL files to the installation 
directory. The main problem for this is to enumerate the needed directories.

I use the same for copying DLL files to the output directory to ease debugging.

The advantage is the inspection of the exe for really needed DLL files. This 
AUTOMATICALLY handles the case debug vs. release.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] DLL handling under CMake

[Michael Jackson]

Our project uses some custom cmake functions to gather the DLLs from 3rd 
party libs (HDF5, TBB, Qt) and create custom targets to copy them to the 
build directory and create install rules to copy them to the package 
when it is created. Yes, they were tedious to write and get correct but 
they seem to work. The Qt version was the easiest after we moved to Qt 5 
since it is straight forward to get the locations. The HDF5 folks 
recently updated their config file to have the same type of information. 
TBB is odd, but relatively easy to guess the correct pattern.


I had a discussion about this topic yesterday and my pain point is that 
a lot of the "Find**" modules really _need_ to also define the DLL 
location instead of just where the link libs are at. From my little 
world on Windows all the .dll files seem to be in a bin directory. So I 
think that for each "Find***" those should define a few additional items:


FOO_IS_SHARED
FOO_BINARY_DIR

assuming of course that the proper FooConfig.cmake is not available.

--
Mike Jackson

PS:: http://www.github.com/bluequartzsoftware/cmp has our custom 
scripts. It is mainly Qt focused but may have some gems in there that 
you find valuable.


Louis-Paul CORDIER wrote:

Hi,

I'm using CMake for a while now for cross-platform project.

In opposition to Linux, Windows does not have a library system
management through a repository system. I would say that 99% of
applications that have common libraries between them does not share the
runtimes. Each time, the .dll files are duplicated for each application.
We have to live with that, and to create proper CMakeLists.txt that can
handle DLL integration.

I think many of CMake users have the following pipeline on Windows:

1. Run CMake (this will execute some find_library to get the correct
.lib files)
2. Compile the application
3. Run the INSTALL target
4. Copy the .dll files into the output binary folder.
5. Package the application with the DLL inside (e.g innosetup)

Currently find_library does not search for runtime, but only for .lib.
So even if a developer is using find_library, he/she has to implement
some additional CMake code to retrieve the path to .dll files and copy
them using the install or the file CMake commands. I added my current
code for handling Qt library in my project at the end of this email. (I
put a huge part of it if someone want to reuse it). You will notice that
this code is handling the case where you are debugging using Visual
Studio, to avoid the missing .DLL issue.

This steps are tedious and I'm wondering if there is a mechanism that
exists or that have to be imagined to make the DLL nightmare end.

All the best

Louis-Paul Cordier


...

#Folder where compiled files for release/debug install will be placed
set(G3_RELEASE_DIR "release")
set(G3_DEBUG_DIR "debug")

find_package(Qt5 ${QT5VC2015_VERSION} EXACT COMPONENTS Core OpenGL
Concurrent REQUIRED)

QT5_WRAP_UI(...)
QT5_WRAP_CPP(...)
target_include_directories(...)
target_compile_definitions(...)

#Add Qt libraries to the linker
target_link_libraries(${PROJECT_NAME}
${Qt5Widgets_LIBRARIES}
${Qt5OpenGL_LIBRARIES}
${Qt5Concurrent_LIBRARIES}
)

if( WIN32 )
SET(QT_DLL
Qt5Core
Qt5Gui
Qt5Widgets
Qt5OpenGL
Qt5Concurrent
)

foreach( _file ${QT_DLL} )
list( APPEND DLL_LIBRARIES "${QT5_DIR}/bin/${_file}.dll" )
list( APPEND DLL_LIBRARIES_D "${QT5_DIR}/bin/${_file}d.dll" )
endforeach( _file ${QT_DLL} )

#TODO: add the platform libraries.

endif( WIN32 )

# I add other DLLs of other project's library by appending to
DLL_LIBRARIES and DLL_LIBRARIES_D

#Handle DLLs under Windows.
if(WIN32)

set(DLL_LIBRARIES_PATH "")
set(DLL_LIBRARIES_D_PATH "")

#Process Release libraries.
foreach( _file ${DLL_LIBRARIES} )

# Convert path to CMake path to avoid escaping issues.
file(TO_CMAKE_PATH ${_file} _file_cmake_path)

#check file existance
if(NOT EXISTS ${_file_cmake_path})
message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}")
endif(NOT EXISTS ${_file_cmake_path})

# Add the DLL to the installation process.
install(FILES ${_file_cmake_path}
DESTINATION ${G3_RELEASE_DIR}
CONFIGURATIONS Release RelWithDebInfo MinSizeRel Release_CMT Release_Net)

# Extract the folder path of the DLL. It allows to add the folder where the
# DLLs are stored to the PATH environment of Visual Studio, in order to
avoid
# copying DLL after each builds.
if(MSVC)
get_filename_component(_dll_folder ${_file} DIRECTORY)
list(APPEND DLL_LIBRARIES_PATH ${_dll_folder})
endif(MSVC)

endforeach( _file ${DLL_LIBRARIES} )

#Process Debug libraries.
foreach( _file ${DLL_LIBRARIES_D} )

# Convert path to CMake path to avoid escaping issues.
file(TO_CMAKE_PATH ${_file} _file_cmake_path)

#check file existance
if(NOT EXISTS ${_file_cmake_path})
message(FATAL_ERROR "Missing dll file: ${_file_cmake_path}")
endif(NOT EXISTS ${_file_cmake_path})

# Add the DLL to the installation process.
install(FILES ${_file_cmake_path}
DESTINATION ${G3_DEBUG_DIR}
CONFIGURATIONS Debug)

# Extract the folder path of