CMAKE_RUNTIME_OUTPUT_DIRECTORY Windows compatibility

[yihuajack]

In CMakeLists.txt,

set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

which will put soci_core and soci_ DLLs under ${CMAKE_BINARY_DIR}/bin. However, on Windows, the executable is just under ${CMAKE_BINARY_DIR} rather than ${CMAKE_BINARY_DIR}/bin. If putting DLLs under ${CMAKE_BINARY_DIR} then the executable would fail to find the soci DLLs.

[vadz]

Sorry, which executable do you mean? I.e. what exactly is the problem and when does it happen?

[yihuajack]

I mean the executable of the program that uses the soci library, which is expected to be located under ${CMAKE_BINARY_DIR} on Windows. The problem is that if adding soci as a thirdparty library for a program on Windows, the program will not find any dlls under ${CMAKE_BINARY_DIR}/bin but ${CMAKE_BINARY_DIR}, so that there will be a dll not found error. One way to solve this is to manually copy soci's dlls from ${CMAKE_BINARY_DIR}/bin to ${CMAKE_BINARY_DIR}, but under some circumstances it is hard to do this copy for compatibility issues. I'm not sure about what's the role of the three settings in soci's CMakeLists.txt (if removing these settings or changes the settings to ${CMAKE_BINARY_DIR} then no problem exists).

[vadz]

Unfortunately I'm not sure about them neither. There is the #1118 (WIP) which aims to streamline all this, but I don't know if it addresses this.

Does your top-level project define CMAKE_RUNTIME_OUTPUT_DIRECTORY? If it does, we could skip setting it if it's already set which should be totally safe, I think.

[Krzmbrzl]

I have built applications on top of #1118 and I don't see any issues even on Windows.

The issue here is likely in the order in which the top-level project includes SOCI. If you first include SOCI, then the runtime output property propagates to your top-level project such that all your target inherit the same property (unless you set it explicitly to something else).
However, any targets declared before including SOCI will not have this property and also won't get it once SOCI is included as the setting merely acts as a default for the given target's property.

Since the output directory property merely serves a cosmetic issue, I would vote for just not explicitly setting these things in SOCI. Then cmake's default will do something that just works on all platforms.
And if any given user has special desires as to where the build artifacts should end up, they can easily set these variables when calling cmake from the command line. That will then also ensure that the result is consistent, avoiding issues such as the one presented here.

---

@vadz as a side-note: feel free to ping me in cmake-related issues. Especially due to my work with the cmake refactoring I a) know a lot about SOCI's existing cmake implementation and b) have an interest in getting to know all issues that people face with the current setup to make sure the new one fixes it :)

[yihuajack]

Thanks for your instruction. Your PR #1118 can fix this issue.