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.
CMAKELISTS.TXT NOT FOUND CLION UPDATE
(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. I definitely agree with OvermindDL1 in the fact that you should have use namespaced targets to go "all the way" with the modernization.Ģ. This isn't true anymore and instead the error message with suggestion CMake throws at you, can finally be implemented.ġ.
CMAKELISTS.TXT NOT FOUND CLION WINDOWS
Windows users (and maybe others) have gotten used to setting SFML_ROOT in order to tell the FindSFML.cmake where to look for SFML. ) you can remove that from your CMake file.
As such if you have some code like SET(CMAKE_MODULE_PATH.
This also means, you no longer have to make sure that FindSFML.cmake can be found in CMAKE_MODULE_PATH. If I change the order of the findpackage calls CMake fails to find boost similarly. If 'Eigen3' provides a separate development package or SDK, be sure it has been installed. You can look for it as long as you want, it doesn't exist anymore, regardless of guide XYZ said, if you use SFML 2.5.0 there's no FindSFML.cmake anymore. Add the installation prefix of 'Eigen3' to CMAKEPREFIXPATH or set 'Eigen3DIR' to a directory containing one of the above files.
This thread should help clarify the required changes to utilize the new SFMLConfig.cmake file. In the last weeks however we've noticed a considered amount of people not realizing the changes and thus wondering what to do with their "broken" build system. With SFML 2.5.0 we have modernized our CMake build system largely thanks for Ceylo!
0 kommentar(er)
