[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-212-gcdb43f1

2017-07-04 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  cdb43f1c887a0695468c18968943680435c7e625 (commit)
  from  74112c8da16ea5f2a4940d196d178da684626f92 (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=cdb43f1c887a0695468c18968943680435c7e625
commit cdb43f1c887a0695468c18968943680435c7e625
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Jul 5 00:01:08 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Jul 5 00:01:08 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 5677a32..7421ef9 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 9)
-set(CMake_VERSION_PATCH 20170704)
+set(CMake_VERSION_PATCH 20170705)
 #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] CMake Server Mode and USE_FOLDERS

2017-07-04 Thread Michael Jackson 
Actually, my comments were spurred on from a discussion on the QtCreator 
list. I am *very* happy with the layout inside of VS2015 that we have 
been able to generate based on the USE_FOLDERS property. QtCreator tends 
to use the Ninja generator to generate the actual build system. 
QtCreator just calls "cmake --build . " when it needs to build your 
project. And since they use the "Ninja" generator (which I think is user 
settable) and Ninja does not support the USE_FOLDERS notion, that 
USE_FOLDERS would need to be implemented in the Ninja generator so that 
CMAKE-Server mode would pass that information? I don't know how 
separated the Cmake-server code model is from the actual generator.


--
Mike Jackson


Nagy-Egri Máté Ferenc via CMake wrote:

I can only speak about VS, which currently neither with the VS nor
the Ninja generator use the FOLDERS property to lay out the targets
inside the Solution Explorer. Instead, it maintains the folder
structure of the CMake project. This was an intentional design
decision from their part (at least for the time being), due to CMake
folks primarily being used to the command line, thus they think in
therms of the folder structure, not the logical layout of the CMake
scripts.

There is a tendency though of hooking all CMake notions into the IDE,
 such as CTests show up Test Explorer. Reach out to the VS CMake team
and let them know that there is such need, perhaps controlled through
a switch.

*Feladó: *Michael Jackson 
*Elküldve: *2017. július 4., kedd 4:08 *Címzett: *Cmake Mailing List
 *Tárgy: *[CMake] CMake Server Mode and
USE_FOLDERS

I was just exploring in a command line the CMake Server mode in 3.8
(I

have not tried 3.9 yet) just to see what gets output and I was
wondering

if CMake-Server mode supports "set_property(GLOBAL PROPERTY
USE_FOLDERS

ON)" for any generator? I was specifically using the "ninja"
generator

for my experiments. I suspect not since Ninja itself does not have
the

concept of this but I though I would inquire.

If IDE's that are now relying on CMake-server had this information
it

would allow the IDE to present the project in such a way that the

developers intended or laid out. I know we put a lot of time into
our

CMake files so that the Visual Studio and Xcode projects are
reasonably

organized when you open them instead of just listing 250 targets.

Thanks for any insights.

Mike Jackson

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html

CMake Consulting: http://cmake.org/cmake/help/consulting.html

CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:

http://public.kitware.com/mailman/listinfo/cmake


--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake Server Mode and USE_FOLDERS

2017-07-04 Thread Florent Castelli 
From what I've read from the VS CMake team at Microsoft in various blog 
posts and online discussions, they plan to have actual targets someday 
in VS instead of the "Open folder" structure they currently have with 
their integration. So right now, that information wouldn't be of any use 
for them since they don't even have a flat list of projects.
It just takes time! Seeing from the progress they've made, I'm sure it 
will eventually come to the product.


/Florent

On 04/07/2017 12:43, Nagy-Egri Máté Ferenc via CMake wrote:


I can only speak about VS, which currently neither with the VS nor the 
Ninja generator use the FOLDERS property to lay out the targets inside 
the Solution Explorer. Instead, it maintains the folder structure of 
the CMake project. This was an intentional design decision from their 
part (at least for the time being), due to CMake folks primarily being 
used to the command line, thus they think in therms of the folder 
structure, not the logical layout of the CMake scripts.


There is a tendency though of hooking all CMake notions into the IDE, 
such as CTests show up Test Explorer. Reach out to the VS CMake team 
and let them know that there is such need, perhaps controlled through 
a switch.


*Feladó: *Michael Jackson 
*Elküldve: *2017. július 4., kedd 4:08
*Címzett: *Cmake Mailing List 
*Tárgy: *[CMake] CMake Server Mode and USE_FOLDERS

I was just exploring in a command line the CMake Server mode in 3.8 (I

have not tried 3.9 yet) just to see what gets output and I was wondering

if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS

ON)" for any generator? I was specifically using the "ninja" generator

for my experiments. I suspect not since Ninja itself does not have the

concept of this but I though I would inquire.

If IDE's that are now relying on CMake-server had this information it

would allow the IDE to present the project in such a way that the

developers intended or laid out. I know we put a lot of time into our

CMake files so that the Visual Studio and Xcode projects are reasonably

organized when you open them instead of just listing 250 targets.

Thanks for any insights.

Mike Jackson

--

Powered by www.kitware.com

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


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


CMake Support: http://cmake.org/cmake/help/support.html

CMake Consulting: http://cmake.org/cmake/help/consulting.html

CMake Training Courses: http://cmake.org/cmake/help/training.html

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


Follow this link to subscribe/unsubscribe:

http://public.kitware.com/mailman/listinfo/cmake





-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake Server Mode and USE_FOLDERS

2017-07-04 Thread Nagy-Egri Máté Ferenc via CMake 
I can only speak about VS, which currently neither with the VS nor the Ninja 
generator use the FOLDERS property to lay out the targets inside the Solution 
Explorer. Instead, it maintains the folder structure of the CMake project. This 
was an intentional design decision from their part (at least for the time 
being), due to CMake folks primarily being used to the command line, thus they 
think in therms of the folder structure, not the logical layout of the CMake 
scripts.

There is a tendency though of hooking all CMake notions into the IDE, such as 
CTests show up Test Explorer. Reach out to the VS CMake team and let them know 
that there is such need, perhaps controlled through a switch.

Feladó: Michael Jackson
Elküldve: 2017. július 4., kedd 4:08
Címzett: Cmake Mailing List
Tárgy: [CMake] CMake Server Mode and USE_FOLDERS

I was just exploring in a command line the CMake Server mode in 3.8 (I 
have not tried 3.9 yet) just to see what gets output and I was wondering 
if CMake-Server mode supports "set_property(GLOBAL PROPERTY USE_FOLDERS 
ON)" for any generator? I was specifically using the "ninja" generator 
for my experiments. I suspect not since Ninja itself does not have the 
concept of this but I though I would inquire.

If IDE's that are now relying on CMake-server had this information it 
would allow the IDE to present the project in such a way that the 
developers intended or laid out. I know we put a lot of time into our 
CMake files so that the Visual Studio and Xcode projects are reasonably 
organized when you open them instead of just listing 250 targets.

Thanks for any insights.

Mike Jackson

-- 

Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] DLL handling under CMake

2017-07-04 Thread Louis-Paul CORDIER 

Hi,

Thank you very much for this code snippet. However I don't like the 
fixup_bundle function, as it takes the first dll that it found to be 
linked against.


I also did a try with a dependency scanning function. It is quiet long 
to write, but I guess it is the cleanest way to handle DLL under Windows.
Note: I still have an issue with this function. Indeed, if user uses 
Generator expressions for library dependencies, it will not work.

e.g:
add_library(Foo_lib IMPORTED GLOBAL)
# ... set location properties
target_link_libraries(${PROJECT_NAME} optimized 
$<$:Foo_lib>)


Any idea for a workaround? What do you think about this CMake code?

Also, I would see a real benefit to add a LINK_DEPENDENT_LIBRARIES 
property (inspired of IMPORTED_LINK_DEPENDENT_LIBRARIES) to each target 
that could be automatically filled by each target_link_libraries() calls.




# This function scan all dependencies of a project recursively, and 
retrieve all shared

# library associated with it.
# Prerequisite: your upstream CMakeLists.txt must make use of 
add_library(foo SHARED IMPORTED GLOBAL),

# and fill the following properties on the imported target:
# set_target_properties(foo PROPERTIES IMPORTED_IMPLIB "path_to_foo.lib")
# set_target_properties(foo PROPERTIES IMPORTED_LOCATION "path_to_foo.dll")
# set_target_properties(foo PROPERTIES IMPORTED_LINK_DEPENDENT_LIBRARIES 
"path_to_dll_on_which_foo_depends.dll")
# GLOBAL keyword is important as it allows downstream CMakeLists.txt to 
scan dependencies.


# Input parameters:
# dep_to_scan: your downstream project
# config_to_scan: configuration to use for the scanning.
# output_variable: variable in which the function stores the result.

# Usage:
# RECURSIVE_SCAN(my_app Release DLLS)
#  install(FILES ${DLLS}
# DESTINATION release
# CONFIGURATIONS Release)

set(COUNT 0)
function(RECURSIVE_SCAN dep_to_scan config_to_scan output_variable)

  MATH(EXPR COUNT "${COUNT}+1")
  string(RANDOM LENGTH ${COUNT} ALPHABET "-" SPACES)

  message("${SPACES} Scanning ${dep_to_scan}")
  if(NOT TARGET ${dep_to_scan})
MATH(EXPR COUNT "${COUNT}-1")
#message("${dep_to_scan} Is not target")
return()
  endif()


  get_target_property(_is_imported ${dep_to_scan} IMPORTED)
  if(_is_imported)

# We need to check if the imported library rely on other shared 
libraries.
get_target_property(_dependent_dll ${_lib} 
IMPORTED_LINK_DEPENDENT_LIBRARIES_${config_to_scan})

if(NOT _dependent_dll)
  get_target_property(_dependent_dll ${_lib} 
IMPORTED_LINK_DEPENDENT_LIBRARIES)

endif()

if(_dependent_dll)
  list(APPEND ${output_variable} ${_dependent_dll})
endif()


#Otherwise, check if it is a shared library. (LOCATION variable can be
# either .lib or DLL regarding of the type of library.)
get_target_property(_TYPE ${dep_to_scan} TYPE)

if(NOT _TYPE STREQUAL STATIC_LIBRARY)
  get_target_property(_dll_found ${dep_to_scan} 
LOCATION_${config_to_scan})

  if(_dll_found)
list(APPEND ${output_variable} ${_dll_found})
  endif()

endif()

message("${SPACES}- DLL found: (${${output_variable}})")

  endif(_is_imported)

  get_target_property(_libraries ${dep_to_scan} INTERFACE_LINK_LIBRARIES)

  if(_libraries)
  foreach(_lib ${_libraries})
RECURSIVE_SCAN(${_lib} ${config_to_scan} ${output_variable})
  endforeach()
  endif()

  # If we reach our first recursion, we need to clean the list of
  # DLL in order to remove duplicates.
  MATH(EXPR COUNT "${COUNT}-1")

  if(${COUNT} EQUAL 0)
list(REMOVE_DUPLICATES ${output_variable})
  endif()

  set(${output_variable} ${${output_variable}} PARENT_SCOPE)

endfunction(RECURSIVE_SCAN)


Best regards,

Louis-Paul CORDIER

Le 04/05/2017 à 09:51, lec...@gmail.com a écrit :


I managed to get it working by using an intermediate script.

One might want to generate the script instead of using the « RUN_IT » 
variable trick.


This was only tested on Windows, but seems to work fine.

Put the following code in a xx.cmake file, include it from your 
CMakeLists.txt and enjoy.


# This is a helper script to run BundleUtilities fixup_bundle as postbuild

# for a target. The primary use case is to copy .DLLs to the build 
directory for


# the Windows platform. It allows generator expressions to be used to 
determine


# the binary location

#

# Usage : run_fixup(TARGET LIBS DIRS)

# - TARGET : A cmake target

# - See fixup_bundle for LIBS and DIRS arguments

if(RUN_IT)

# Script ran by the add_custom_command

include(BundleUtilities)

fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}")

# End of script ran by the add_custom_command

else()

set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE})

message(${THIS_FILE})

function(run_fixup _target _libs _dirs)

message(${THIS_FILE})

add_custom_command(

   TARGET ${_target} POST_BUILD

   COMMAND ${CMAKE_COMMAND}