Specify CMAKE_RUNTIME_OUTPUT_DIRECTORY from outside of the project
#2745
Conversation
Hardcoding this into the library itself means that outside consumers cannot choose a different value. This in particular breaks the CMake template project of ours which also tries to set this value. As conventional wisdom dictates, its best to not touch CMAKE_ variables unless necessary. Luckily our use of presents means we can easy move this into the development preset.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2745 +/- ##
=======================================
Coverage 38.32% 38.32%
=======================================
Files 237 237
Lines 20801 20801
Branches 5148 5148
=======================================
Hits 7973 7973
- Misses 11795 11815 +20
+ Partials 1033 1013 -20 see 42 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
Found this whilst using the template project, altered to target master. I regularly use the current state of master. I noticed that the DLLs weren't being output to the expected directory |
|
What do you want to do about buildbot? |
|
The Mesa3D stuff hardcodes a reference to |
Description
Hardcoding this into the library itself means that outside consumers cannot choose a different value. This in particular breaks the CMake template project of ours which also tries to set this value. It resulted in the DLLs not being placed in build/bin as expected but rather build/_deps/sfml-build/bin.
As conventional wisdom dictates, it's best to not touch
CMAKE_variables unless necessary. Luckily our use of presents means we can easy move this into the development preset so there are no ergonomics disadvantages to this.This problem is not present in SFML 2 because that version does not manipulate
CMAKE_RUNTIME_OUTPUT_DIRECTORY. Luckily now that the template project defaults to static libs these DLL issues are harder to run into.Thanks to @Bambo-Borris for reporting this.