Use default cmake output paths #3572
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Test failure is a good example of the issues sharing an output directory can cause - As the tests still share an output directory (by virtue of being in the same CMakeLists) there's a race condition as each target tries to update files in the output folder when building in parallel Seems like they should just use separate cmakelists as we do in the rest of the project (and is generally good practice) - Have made that change in #3573 |
|
#2745 is another issue caused by this setting, and would be superseded by this change |
5 tasks
256b879 to
fd88b2d
Compare
|
SFMLBuildMaster: Build this please. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overriding the global
CMAKE_RUNTIME_OUTPUT_DIRECTORYvariable so that every binary goes into the same folder is intrusive, unintuitive, and can cause a variety of unnecessary complicationsMy understanding is this was only done so that windows dlls can be loaded for the examples/tests, but it's simple enough to do that in a target and platform specific way that leaves the standard output structure untouched.
Had to modify the mesa3d stuff to accommodate this, which also removed the functionality to remove the mesa3d dlls when disabling the option, but given it's just a workaround for CI jobs (where this behaviour would never be used) I think the impact of this is negligible - I could make it work with some more hacks but in my opinion it's not worth it for something that maintaners/developers may only do once in a blue moon (you can just do a clean build instead when disabling the option)
A big motivation for this is mobile/console ports, where the output is often more than just a simple binary, and involves specific folder structures that are difficult (or impossible) to manage when every target is trying to work with the same output folder