|
Notes |
|
|
(0013503)
|
|
Bill Hoffman
|
|
2008-09-17 22:28
|
|
|
We already have this in CMake. See Modules/InstallRequiredSystemLibraries.cmake |
|
|
|
(0013504)
|
|
Bill Hoffman
|
|
2008-09-17 22:51
|
|
|
Sorry, note the same thing. Can you describe how you use this macro? |
|
|
|
(0013507)
|
|
Mike McQuaid
|
|
2008-09-18 07:27
|
|
Basically this copies files into the binary output directory BEFORE installation.
Example usage:
install_to_msvc_build_directory(
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
"dependency_library.dll"
) |
|
|
|
(0013633)
|
|
Bill Hoffman
|
|
2008-10-01 09:24
|
|
|
So, dependency_library.dll has to exist at CMake time right? Also, this seems to copy the lib into Debug, Release and all configurations, what if you have different types of .dlls for each of them? I don't think this is general enough to be supported in Cmake. |
|
|
|
(0013634)
|
|
Mike McQuaid
|
|
2008-10-01 09:41
|
|
If I made it correctly parse the debug/optimized lines for the debug/optimized builds would that be sufficient?
I do think this is pretty useful to MSVC developers in some form and would be willing to try and adapt it to a form which you think could be included. |
|
|
|
(0013638)
|
|
Bill Hoffman
|
|
2008-10-01 10:01
|
|
|
I am still not seeing how that would work? Where does dependency_library.dll come from? |
|
|
|
(0013643)
|
|
Mike McQuaid
|
|
2008-10-01 10:30
|
|
|
Either already installed somewhere else on the system (e.g. Qt) or a third-party proprietary library that is in the source tree. |
|
|
|
(0013644)
|
|
Bill Hoffman
|
|
2008-10-01 10:36
|
|
|
This seems more like something the user should use the PATH for. Coping dll's is a bit dangerous. If it is for install time, then GetPrequisites would be the thing to use for this. But if it is for development time, it should be up to the user to set the PATH or copy the files. |
|
|
|
(0013699)
|
|
Mike McQuaid
|
|
2008-10-02 05:09
|
|
Fair enough, I just found our developers who were used to using MSVC build systems were really uncomfortable when we transitioned to CMake because they were no longer able to run/debug from the IDE without manually copying all the necessary files across to the relevant MSVC directories (as MSVC does this for them).
I don't think setting PATH on a per-project basis is the best answer to this but it's your call. If you think there is a better solution I could have a go at implementing it. |
|
|
|
(0013700)
|
|
Mike McQuaid
|
|
2008-10-02 05:18
|
|
Sorry, you probably meant the MSVC project path not the system one.
Is it possible to adapt the generator to add specified directories to the MSVC path, so this isn't overwritten when CMake is rerun and the PATH doesn't need to be IDE-wide. |
|
|
|
(0013701)
|
|
Bill Hoffman
|
|
2008-10-02 09:15
|
|
|
So, what did your developers do before? |
|
|
|
(0013702)
|
|
Bill Hoffman
|
|
2008-10-02 09:16
|
|
|
No, it is not possible to change the PATH from the generator. That information is not stored in the file. |
|
|
|
(0013705)
|
|
Mike McQuaid
|
|
2008-10-02 10:04
|
|
Before we moved to CMake they had a Visual Studio prebuild action which copied all the necessary files to the build directory (as my module does).
If it isn't possible to change the PATH from the generator does that mean it shouldn't be overwritten either? |
|
|
|
(0013706)
|
|
Bill Hoffman
|
|
2008-10-02 10:08
|
|
|
Then, you should use a custom command which would work just like your prebuild did before. |
|
|
|
(0014102)
|
|
Philip Lowman
|
|
2008-11-13 11:45
|
|
For what it's worth this is something that we have solved as well using custom commands (although I like the idea of using configure_file better now that I see what Mike has done since generally the DLLs don't change after configure time).
By far the biggest pain to implementing this is making it easy for people to just make CMake do the copy. Really all that's needed here are some examples and convenience macros (most probably just a few lines long) and if properly written they could definitely solve Bill's concerns about different build configurations especially if the FOR loop that iterates through ${CMAKE_CONFIGURATIONS} is modified to simply iterate through a user specified list of configurations.
Here's what I have in mind (perhaps I'll create a feature request for this).
INCLUDE(DllCopyHelper)
FIND_PACKAGE(FOO)
IF(FOO_FOUND)
# Take advantage of the fact that 90% of the time it is acceptable to simply
# copy all of the DLLs in PACKAGE_PREFIX/lib/../bin to the build directory
# and that most of the time this is where the DLLs are located
GET_ALL_DLLS(foo_dlls ${FOO_LIBRARY})
COPY_FILES_TO_MSVC_BUILD_TREES(${CMAKE_CONFIGURATIONS} ${foo_dlls})
INSTALL(FILES ${foo_dlls} DESTINATION bin)
ENDIF()
For users that need to differentiate between Debug and Release due to DLLs not having debug postfixes, or for DLLs that are located somewhere other than PREFIX/bin, or perhaps the user doesn't want to copy all DLLs or for some other reason, additional macros could be provided:
IF(FOO_FOUND)
# Allow the users to specify paths relative to detected library and/or
# identify specific DLL files
GET_SOME_DLLS(foo_debug_dlls ${FOO_LIBRARY} ../bin/Debug foo.dll foo_bar.dll)
GET_SOME_DLLS(foo_release_dlls ${FOO_LIBRARY} ../bin/Release foo.dll foo_bar.dll)
# Also, macros could be provided for the Makefile generator
# that don't perform the forloop
IF(MINGW)
COPY_FILES_TO_RUNTIME_OUTPUT_PATH(${foo_mingw_dlls})
ELSE()
COPY_FILES_TO_MSVC_BUILD_TREES(Debug ${foo_debug_dlls})
ENDIF()
INSTALL(FILES ${foo_release_dlls} DESTINATION bin)
ENDIF() |
|
|
|
(0014592)
|
|
Philip Lowman
|
|
2009-01-16 12:55
|
|
I never really heard any feedback on this. Are there any objections to something like this being designed and added? I think it would be a good thing for new CMake users on Windows. Obviously it would be completely opt-in by the user having to add things to their CMakeLists.txt.
The code could also be used to optionally copy the Microsoft runtime DLLs and manifest files to the build tree. We do this right now because we prefer not to "make install" in order to test our code out in the lab (not all of the computers have the 2005 C++ runtime installed on them). |
|
|
|
(0021742)
|
|
Mike McQuaid
|
|
2010-08-13 08:28
|
|
|
Ping on this again from my end. Can you either close it or give us more guidance on how a patch could be made that would be included here? |
|
|
|
(0023909)
|
|
Mike McQuaid
|
|
2010-12-13 07:05
|
|
4 months later ping. If I shouldn't be bugs on the bug tracker can you suggest the best way of getting these looked at?
Thanks! |
|
|
|
(0023923)
|
|
Bill Hoffman
|
|
2010-12-13 09:44
|
|
You should bring this up on the cmake-developer mailing list. This is not really a bug, but rather a feature request. Since the feature can be implemented inside a project, not adding this to CMake does not really impact your project. Adding it to CMake means that CMake devs have to support this forever into the future. I am not sold on the idea that we need this feature. The easiest code to maintain is the code you never wrote... :)
That said, if you could get consensus on the cmake-developers list, I have changed my mind in the past. |
|
|
|
(0024457)
|
|
Mike McQuaid
|
|
2011-01-06 09:36
|
|
|
Thinking about this, you could do it fairly easily with BundleUtilities so this can probably be closed. |
|
|
|
(0024477)
|
|
David Cole
|
|
2011-01-06 15:28
|
|
|
Resolving since reporter says "this can probably be closed" |
|
|
|
(0026319)
|
|
David Cole
|
|
2011-05-02 14:45
|
|
|
Closing resolved issues that have not been updated in more than 3 months. |
|
InstallToMSVCBuildDirectory.cmake (1,104) 2008-09-17 11:18