![]() That’s basically my view of Windows yeah. People often assume that the DLL must be in the same directory as the executable, Might ask another question here regarding that. But there is still some work need to be done supporting also components and stuff like that … and I’m not sure if I have understood yet how that correctly works. I plan to do a pull request as soon as I have something working good. ![]() I know, I read your book I hacked in the source code of soci itself because it seems like mloskot isn’t active anymore. ![]() It might be annoying for developers to have it getting invoked every time the target is built though. That file() subcommand is more intended for use at install time, but I’d assume you could probably get it to work at build time. If you really want to go down the path of copying DLLs next to your binary though, you could try taking a look at using file(GET_RUNTIME_DEPENDENCIES) in conjunction with add_custom_command(TARGET someTarget POST_BUILD. CMake currently doesn’t provide any help to you for this, so you’re on your own with it unfortunately. If you’re looking for a convenient way to invoke an executable outside of those contexts, a common way of handling that is to write your own launch script that augments the PATH before launching the executable. Writing your own user.props file if you are using an earlier version of CMake that doesn’t have support for VS_DEBUGGER_ENVIRONMENT but does support the VS_USER_PROPS target property.Using the VS_DEBUGGER_ENVIRONMENT target property (this takes care of invoking executables within the Visual Studio IDE).Using the ENVIRONMENT test property to set the PATH environment variable for you (this takes care of invoking executables as part of ctest runs).For everyone else, the techniques there talk about: Since you mentioned that you have my book, look in the Project Organization -> Windows-specific Issues section which goes through different approaches. There are a few ways of augmenting your PATH, depending on how you want to be launching the executable. If you want to avoid copying around DLLs (something I generally advise avoiding if you can), you will need to augment your PATH environment variable before launching the executable. People often assume that the DLL must be in the same directory as the executable, but that’s just one way for the OS to find the DLL when running that executable. It is a different story for running an executable. The target_link_libraries() doesn’t (and shouldn’t) copy DLLs for you, there is no requirement that a DLL be in the same directory as the executable that uses it. For linking, CMake should do the right thing and link DLLs without having to copy them around. Putting DLLs “in the right place” implies a particular view of how those DLLs should be handled. I think was working on improved CMake support for the 4.0 SOCI release, but I’m not sure what state that got to. SOCI should be taking care of specifying all the relevant dependencies as part of that. You shouldn’t be writing a SOCIConfig.cmake file, that file should be provided by SOCI itself. What’s the correct (platform independent) solution to make it work conveniently on Windows as well as Linux? via a cmake function … but that doesn’t seem right to me?Īfter all that’s the purpose of target_link_libraries isn’t it? I have read in several places solutions like copying the dlls. ![]() If I say target_link_libraries(someTarget someOtherDynamicLibTarget), I assumed that cmake would do the job for me and put the dlls in the right place. Manually copying them in the directory solves that issue, but that doesn’t seem right to me. If I build my application it’s missing all the dlls of soci as well as sqlite3. I have another problem on Windows, which I don’t have on Linux (due to the fact that libs are in a known place I guess). How can I achieve that does headers will be included automatically as well? So I don’t have to include the headers of soci anymore, but still the headers of sqllite (in order that the soci headers work). Soci itself has dependencies to sqllite3. So that’s actually working fine for that target, but the problem is with dependencies. To automatically include the right headers I did add such a line to the install commands of the targets: This allow me to link against cmake targets. Install(EXPORT SOCI NAMESPACE SOCI:: DESTINATION cmake FILE SOCIConfig.cmake) So I basically created a (very simple) sociConfig.cmake how it is explained in “Professional cmake” by doing: Maybe some of you have suggestions on how to make that better. ![]() But there are still a few problems, which I solve with ways I don’t like After days of hacking around, I got it working. I’m currently trying to include a lib (soci) in my cmake projects. ![]()
0 Comments
Leave a Reply. |