Re: [CMake] DLL handling under CMake

[Clément Gregoire]

t_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} -DRUN_IT:BOOL=ON
> -DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> -DTO_FIXUP_LIBS=${_libs}
> -DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}
>
>COMMENT "Fixing up dependencies for
> ${_target}"
>
>VERBATIM
>
> )
>
>
>
> endfunction()
>
>
>
> endif()
>
>
>
>
>
> *De : *Clément Gregoire <lec...@gmail.com>
> *Envoyé le :*jeudi 4 mai 2017 08:37
> *À : *Hendrik Sattler <p...@hendrik-sattler.de>; Louis-Paul CORDIER
> <lp.cord...@dynamixyz.com>; Cmake Mailing List <cmake@cmake.org>
> *Objet :*Re: [CMake] DLL handling under CMake
>
>
>
> I'd also be interested in this. I saw an old mail in the ML about this,
> but it seems fixup_bundle is old and cant use generator expressions, making
> it hard to use (I don't want to hardcode the executable path).
>
>
>
> Do you have a sample for this ?
>
> CMake would really benefit from having those features made more accessible
> instead of everyone having to write its own script
>
> Le sam. 29 avr. 2017 22:10, Hendrik Sattler <p...@hendrik-sattler.de> a
> écrit :
>
>
>
> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER <
> lp.cord...@dynamixyz.com>:
> >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
>
>
>
>
>
> --
>
> 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

[Louis-Paul CORDIER]

# 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} 
-DRUN_IT:BOOL=ON -DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> 
-DTO_FIXUP_LIBS=${_libs} -DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}


   COMMENT "Fixing up dependencies for 
${_target}"


   VERBATIM

)

endfunction()

endif()

*De : *Clément Gregoire <mailto:lec...@gmail.com>
*Envoyé le :*jeudi 4 mai 2017 08:37
*À : *Hendrik Sattler <mailto:p...@hendrik-sattler.de>; Louis-Paul 
CORDIER <mailto:lp.cord...@dynamixyz.com>; Cmake Mailing List 
<mailto:cmake@cmake.org>

*Objet :*Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about 
this, but it seems fixup_bundle is old and cant use generator 
expressions, making it hard to use (I don't want to hardcode the 
executable path).


Do you have a sample for this ?

CMake would really benefit from having those features made more 
accessible instead of everyone having to write its own script


Le sam. 29 avr. 2017 22:10, Hendrik Sattler <p...@hendrik-sattler.de 
<mailto:p...@hendrik-sattler.de>> a écrit :




Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
<lp.cord...@dynamixyz.com <mailto:lp.cord...@dynamixyz.com>>:

>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 <http://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

[Louis-Paul CORDIER]

add_custom_command(

   TARGET ${_target} POST_BUILD

   COMMAND ${CMAKE_COMMAND} 
-DRUN_IT:BOOL=ON -DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> 
-DTO_FIXUP_LIBS=${_libs} -DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}


   COMMENT "Fixing up dependencies for 
${_target}"


   VERBATIM

)

endfunction()

endif()

*De : *Clément Gregoire <mailto:lec...@gmail.com>
*Envoyé le :*jeudi 4 mai 2017 08:37
*À : *Hendrik Sattler <mailto:p...@hendrik-sattler.de>; Louis-Paul 
CORDIER <mailto:lp.cord...@dynamixyz.com>; Cmake Mailing List 
<mailto:cmake@cmake.org>

*Objet :*Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about 
this, but it seems fixup_bundle is old and cant use generator 
expressions, making it hard to use (I don't want to hardcode the 
executable path).


Do you have a sample for this ?

CMake would really benefit from having those features made more 
accessible instead of everyone having to write its own script


Le sam. 29 avr. 2017 22:10, Hendrik Sattler <p...@hendrik-sattler.de 
<mailto:p...@hendrik-sattler.de>> a écrit :




Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
<lp.cord...@dynamixyz.com <mailto:lp.cord...@dynamixyz.com>>:

>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 <http://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

[Hendrik Sattler]

Hi,

sorry for the delay. I see you already found a solution yourself.
Still, I want to share mine:
-CopyPrerequisites.cmake
include ( GetPrerequisites )

if ( NOT DEFINED PREREQ_FILE )
  message ( FATAL_ERROR "PREREQ_FILE must be defined(${PREREQ_FILE})" )
endif ()

#
# Satisfy the find_file() search by common subdirs where .dll file can  
be found

#
foreach ( dir ${CMAKE_PREFIX_PATH} )
  list ( APPEND dirs ${dir}/bin )
endforeach ( dir )

get_filename_component ( COPY_DESTINATION "${PREREQ_FILE}" PATH )
get_prerequisites ( "${PREREQ_FILE}" COPY_FILES 1 1 "${dirs}"  
"${COPY_DESTINATION}" )


foreach ( COPY_FILE ${COPY_FILES} )
  if ( NOT IS_ABSOLUTE ${COPY_FILE} )
set ( COPY_FILE_FULL )
gp_resolve_item ( "${PREREQ_FILE}" "${COPY_FILE}" "${dirs}"  
"${COPY_DESTINATION}" COPY_FILE_FULL )

  else ()
set ( COPY_FILE_FULL ${COPY_FILE} )
  endif ()
  if ( COPY_FILE_FULL )
get_filename_component ( COPY_SOURCE_DIR "${COPY_FILE_FULL}" PATH )
if ( NOT COPY_SOURCE_DIR MATCHES "^${COPY_DESTINATION}$" )
  message ( "Copying ${COPY_FILE_FULL} to output directory" )
  execute_process ( COMMAND "${CMAKE_COMMAND}" -E  
copy_if_different "${COPY_FILE_FULL}" "${COPY_DESTINATION}" )

endif ()
  else ()
message ( "Failed to find  ${COPY_FILE}" )
  endif ()
endforeach ( COPY_FILE )
--

This can now be called from CMakeLists.txt:
if ( CMAKE_RUNTIME_OUTPUT_DIRECTORY )
  add_custom_command ( TARGET Gui POST_BUILD
COMMAND ${CMAKE_COMMAND}
"-DCMAKE_PREFIX_PATH:PATH=${SOME_SEARCH_DIRS}"
"-DPREREQ_FILE=$"
-P ${CMAKE_SOURCE_DIR}/CMakeModules/CopyPrerequisites.cmake
VERBATIM
  )
endif ()

The variable SOME_SERACH_DIRS is filled with e.g. IMPORTED_LOCATION  
property values.
The same variable is used when calling INSTALL(CODE ".   
fixup_bundle(...)" )


Regards,

HS

Zitat von lec...@gmail.com:


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} -DRUN_IT:BOOL=ON  
-DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> -DTO_FIXUP_LIBS=${_libs}  
-DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}

COMMENT "Fixing up dependencies for ${_target}"
VERBATIM
)

endfunction()

endif()


De : Clément Gregoire
Envoyé le :jeudi 4 mai 2017 08:37
À : Hendrik Sattler; Louis-Paul CORDIER; Cmake Mailing List
Objet :Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about  
this, but it seems fixup_bundle is old and cant use generator  
expressions, making it hard to use (I don't want to hardcode the  
executable path).


Do you have a sample for this ?
CMake would really benefit from having those features made more  
accessible instead of everyone having to write its own script 
Le sam. 29 avr. 2017 22:10, Hendrik Sattler  
<p...@hendrik-sattler.de> a écrit :



Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER  
<lp.cord...@dynamixyz.com>:

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

Re: [CMake] DLL handling under CMake

[lectem]

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} -DRUN_IT:BOOL=ON 
-DTO_FIXUP_FILE=$<TARGET_FILE:${_target}> -DTO_FIXUP_LIBS=${_libs} 
-DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}
COMMENT "Fixing up dependencies for ${_target}"
VERBATIM
)

endfunction()

endif()


De : Clément Gregoire
Envoyé le :jeudi 4 mai 2017 08:37
À : Hendrik Sattler; Louis-Paul CORDIER; Cmake Mailing List
Objet :Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about this, but it 
seems fixup_bundle is old and cant use generator expressions, making it hard to 
use (I don't want to hardcode the executable path).

Do you have a sample for this ?
CMake would really benefit from having those features made more accessible 
instead of everyone having to write its own script 
Le sam. 29 avr. 2017 22:10, Hendrik Sattler <p...@hendrik-sattler.de> a écrit :


Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
<lp.cord...@dynamixyz.com>:
>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

-- 

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

[Clément Gregoire]

I'd also be interested in this. I saw an old mail in the ML about this, but
it seems fixup_bundle is old and cant use generator expressions, making it
hard to use (I don't want to hardcode the executable path).

Do you have a sample for this ?
CMake would really benefit from having those features made more accessible
instead of everyone having to write its own script

Le sam. 29 avr. 2017 22:10, Hendrik Sattler  a
écrit :

>
>
> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER <
> lp.cord...@dynamixyz.com>:
> >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
>
-- 

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

[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 

Re: [CMake] DLL handling under CMake

[Nils Gladitz]

On 04/27/2017 10:43 AM, Louis-Paul CORDIER wrote:

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.


FWIW in case of Qt5 you do not have to manually construct or guess DLL 
locations.


You can retrieve the DLL locations from the imported targets (e.g. 
"Qt5::Widgets") that Qt5 provides by querying the LOCATION_ 
target properties (e.g. LOCATION_DEBUG or LOCATION_RELEASE).


Nils
--

Powered by www.kitware.com

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

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

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

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

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

[CMake] DLL handling under CMake

[Louis-Paul CORDIER]

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 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_D ${_dll_folder})
endif(MSVC)

  endforeach( _file ${DLL_LIBRARIES_D} )

  if(MSVC)
#Remove duplicate entries
list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH)
list(REMOVE_DUPLICATES DLL_LIBRARIES_PATH_D)

#Set architecture
if(ARCH_X64)
  set(DLL_LIBRARIES_ARCH "x64")
else(ARCH_X64)
  set(DLL_LIBRARIES_ARCH "Win32")
endif(ARCH_X64)

# The output file goes in the build dir.
# @ONLY means only variables of the form @VAR@ will be substituted.
# This method need DLL_LIBRARIES_ARCH, DLL_LIBRARIES_PATH and 
DLL_LIBRARIES_PATH_D
# variables to be set. DONT FORGET TO RESTART VISUAL STUDIO if DLL 
paths changes, as

# vcxproj.user files are loaded only once