Why is SFML still using CMake 2.8 ?

[Ceylo]

Hello,

I see that in the main CMakeLists.txt, SFML requires at least CMake 2.8.3. Which is now quite old : it is referenced as "Older Reference Documentation" when your look for its documentation, and was released 2 years ago.

The other reason I'm asking this is because CMake 3 provides a feature (and probably many others) that would be quite useful for all projects that use both CMake and SFML: interface libraries.
I have found one similar post from 2014 about it : cmake 3.0: Config-file Packages. But it's not available with FindSFML.cmake at the moment.

Basically this would mean one could write:

find_package(SFML 2 COMPONENTS network system)
target_link_library(MyExe PRIVATE sfml)

And that's all. Automatic handling of debug/release versions of SFML, not need to care about SFML_INCLUDE_DIR or SFML_DEPENDENCIES (static case would be written exactly the same).

So is it "just" a matter of doing it or there are other reasons?

Ceylo

[eXpl0it3r]

Many Linux distros only ship CMake 2.x as such we can't really raise the minimum required version and being "older" doesn't necessarily mean, being worse off.
However this doesn't mean, we potentially couldn't support newer CMake features via a conditional check. Checkout the open GitHub issues (#758, #937) and feel free to discuss potential adjustments before creating a pull request, if you're interested in contributing.

[Laurent]

So is it "just" a matter of doing it

This. "Modern CMake" is so much better than what we have.

[Ceylo]

Many Linux distros only ship CMake 2.x as such we can't really raise the minimum required version and being "older" doesn't necessarily mean, being worse off.

I'm curious to know which ones still stick with CMake 2. Even Debian which (from what I know) takes time to adopt newer packages provides CMake 3.7 through apt-get as of Debian 9. 

However this doesn't mean, we potentially couldn't support newer CMake features via a conditional check. Checkout the open GitHub issues (#758, #937) and feel free to discuss potential adjustments before creating a pull request, if you're interested in contributing.

Indeed it could be conditional even if I prefer a simple unique version to do things I've had a look at these threads, they go even further: define SFML targets AND remove the need for the FindSFML.cmake file (but add the need for the config file). I don't know yet this config file approach so will study it a bit. Especially I don't have seen it used widely so I wonder if this is the way to go.

So is it "just" a matter of doing it

This. "Modern CMake" is so much better than what we have.

For a few seconds I wondered if it was sarcastic

[Laurent]

As far as I know, the "right" way to do it is to create those config files (automatically generated) that define all the SFML libraries as imported targets, with all the public headers, dependencies and compiler flags that come with them, automatically defined.
Then, as a user, you just tell CMake where the config file is, and you target_link_libraries(your_project sfml::graphics etc.) and that's it.

So no, it was not sarcastic

[eXpl0it3r]

I'm curious to know which ones still stick with CMake 2. Even Debian which (from what I know) takes time to adopt newer packages provides CMake 3.7 through apt-get as of Debian 9. 

Oh well, looks like time has passed since the last discussions.

[Ceylo]

Oh well, looks like time has passed since the last discussions.

Does it mean there is no reason anymore to keep CMake 2.8 ?

[Laurent]

As far as I'm concerned, we can switch to CMake 3.

[eXpl0it3r]

I sent a mail off to the SFML Debian package maintainer to get his insight on the state of CMake versioning.

[Ceylo]

I've started doing the changes to support config file generation. At the moment this is working at least for me on macOS with frameworks. I expect it to work on other platforms too because it reuses the definitions of current SFML targets. This implies a LOT of changes though so I would like your feedback before going on.

The current diff: https://github.com/SFML/SFML/compare/master...Ceylo:feature/CMakeTargetExport

Especially I have replaced all the listing of dependencies with calls to target_link_libraries() and target_include_directories() for 3 reasons:
- this avoids redoing what CMake already does (target_link_libraries() and target_include_directories() already handle lists)
- this makes it easier to group the full setup (include+link) of each dependency
- this will allow specifying which dependencies must be public in case of static linking (what SFML_DEPENDENCIES currently does in FindSFML.cmake), same eventually if compile definitions or include dirs must be exported (currently only the root include dir of SFML is exported)

In terms of usage right now (example from sfeMovie):

find_package (SFML 2.3 COMPONENTS graphics window system audio REQUIRED)
target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-window sfml-system sfml-audio)

I didn't expose yet the fact that sfml-graphics depends on sfml-window and sfml-system. Could be done and would allow writing only

target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-audio)

Dunno yet if we want that though.

PS: does your CI allow testing branches before the PR is open? This way I can quickly see whether I broke something on other platforms.

[eXpl0it3r]

I'd recommend to just open a PR. It doesn't have to mean that it's the final version, but it gives us a nicer diff, a way to review and comment on the changes and allows for triggering the CI system.

[Ceylo]

Done there: https://github.com/SFML/SFML/pull/1335
Still wondering how I can trigger your CI though review needs to be finished first? (a bit odd for me as I'm used to running the CI while review is being done at my workplace, to avoid delaying more than necessary)

[eXpl0it3r]

Just found James' response in my junk mail:

Here are the versions of CMake in Debian / Ubuntu which might be relevant:
 
Ubuntu 12.04 Precise (EOL) = 2.8.7
Debian 7 Wheezy (EOL)      = 2.8.9
Ubuntu 14.04 Trusty        = 2.8.12
Debian 8 Jessie            = 3.0.2
Ubuntu 16.04 Xenial        = 3.5.1
Debain 9 Stretch           = 3.7.2
Ubuntu 17.10 Artful        = 3.9.1
 
Ubuntu 18.04 Bionic (dev)  = 3.9.5
Debian 10 Buster (dev)     = 3.9.5
 
I think you definitely want to support Xenial and Stretch which are the
latest "big" versions of both distros. This would mean a minimum version
of 3.5. Beyond that it's up to you how much you want to support.

So it seems totally safe to raise the minimum version.

[Ceylo]

Awesome! Might be my next PR after the 2 current ones if nobody else takes care of it in the meantime

[Ceylo]

The old CMake requirement is playing tricks to me for the PR about config file.
I identified an issue that gets fixed just by updating CMake requirement, so will do a PR to update CMake requirement first.

Especially I hadn't realized that changing the required CMake version changes the default CMake policies.