[CMake] What do Visual Studio users do so they can run/debug their programs when using 3rd party .dlls?

[J Decker]

INCLUDE(InstallRequiredSystemLibraries)
INSTALL( FILES ${CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS} DESTINATION
${BINARY_OUTPUT_DIR} )

but that doesn't cover third party libraries; which should be in the path
anyway.

Oh; but that's install... so I don't use projects to run, I set the debug
properties of like ALL_BUILD to the executable I want and the path I want;
and build target install....


from "cmake useful variables"  might be useful

CMAKE_CFG_INTDIR meta-variable! Please note that this is an
*important* variable,
since on multi-configuration generators it will be generated into *dynamically
switched* content based on the configuration that the user currently
selected within the generated build environment. Indicates the name of the
current configuration (~ directory) for the project. May be used for any
purpose which needs per-configuration-dynamic switching of strings, not
just OutputDir configuration. For multi-configuration generators (e.g.
MSVC) the resulting strings are typically some of "Debug", "Release",
"RelWithDebInfo", or "MinSizeRel". For other compiler generators
(single-configuration ones) it is typically ".", as they don't use
MSVC-style configuration directories.



On Fri, May 23, 2014 at 4:54 PM, Eric Wing <ewmailing at gmail.com> wrote:

> On 5/23/14, Dan Kegel <dank at kegel.com> wrote:
> > On Fri, May 23, 2014 at 4:38 PM, Eric Wing <ewmailing at gmail.com> wrote:
> >> On 5/23/14, Dan Kegel <dank at kegel.com> wrote:
> >>> You can add the directory containing the 3rd party DLLs to the global
> >>> PATH environment variable, I bet.
> >>
> >> ... I just want a
> >> work-out-of-the-box solution with CMake doing local copies.
> >
> > So... copy the DLLs to the same folder as your test app?
>
> So that's what I think I want, unless there is a smarter way. (As I
> said, changing the global environment isn't really a good option...a
> local per-project setting would be cool though.) Since Visual Studio
> can change these directories depending on the configuration, is there
> a robust CMake way that most of the community already uses to solve
> this?
>
> >
> >>> http://msdn.microsoft.com/en-us/library/ms235299.aspx
> >> I've read that. This is my goal which I want to do with CMake.
> >> "you can directly install redistributable Visual C++ DLLs in the
> >> application local folder"
> >
> > http://msdn.microsoft.com/en-us/library/dd293565.aspx is a bit more
> > explicit.
>
> "Copy the appropriate MFC and C Run-Time (CRT) library files--for
> example, for an x86 platform and Unicode support, copy mfc100u.dll and
> msvcr100.dll from \Program Files\Microsoft Visual Studio
> 10.0\VC\redist\x86\--and then paste them in the \Release\ folder of
> your MFC project."
>
> So again, is there something that already exists that the CMake
> community is using? Finding both the path to the Visual Studio version
> you are using and the CMake/Visual Studio build directory (what if I
> want "MinSizeRel" instead of "Release") is going to be full of little
> gotchas that I know I will screw up if I have to write everything from
> scratch. I am kind of hoping there is already a pre-canned solution
> CMake users are using since this is a common issue.
>
> Thanks,
> Eric
> --
> Beginning iPhone Games Development
> http://playcontrol.net/iphonegamebook/
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140523/3fcd6bb4/attachment.html>