1
General / Re: SFML 2.5 CMake Migration
« on: July 18, 2018, 03:14:05 pm »
1. I definitely agree with OvermindDL1 in the fact that you should have use namespaced targets to go "all the way" with the modernization.
2. (This is a bit of a nitpicking) Assuming that SFML follows something like Semantic Versioning for its own versions (where major changes represent overhauls, minor changes are for additions WITHOUT BREAKING backwards compatibility, patch changes are for bugfixes, etc.), doesn't including this CMake change in a minor version break backwards compatibility? Now it seems that someone using CMake cannot simply (reasonably) try and update their code to use SFML 2.5 (Assuming they don't use the older FindSFML.cmake, which might not be compatible anymore due to the somewhat different folder structure, although I haven't tested this to make sure) without having to deal with changing the CMake code a little bit. Now obviously, this isn't a major problem, but TBH, I would have preferred a breaking change such as this one to be implemented in SFML 3.0, because then an overhaul of everything is logical.
2. (This is a bit of a nitpicking) Assuming that SFML follows something like Semantic Versioning for its own versions (where major changes represent overhauls, minor changes are for additions WITHOUT BREAKING backwards compatibility, patch changes are for bugfixes, etc.), doesn't including this CMake change in a minor version break backwards compatibility? Now it seems that someone using CMake cannot simply (reasonably) try and update their code to use SFML 2.5 (Assuming they don't use the older FindSFML.cmake, which might not be compatible anymore due to the somewhat different folder structure, although I haven't tested this to make sure) without having to deal with changing the CMake code a little bit. Now obviously, this isn't a major problem, but TBH, I would have preferred a breaking change such as this one to be implemented in SFML 3.0, because then an overhaul of everything is logical.