SFML community forums

General => General discussions => Topic started by: Ceylo on December 23, 2017, 03:09:31 pm

Title: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on December 23, 2017, 03:09:31 pm
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 (https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries).
I have found one similar post from 2014 about it : cmake 3.0: Config-file Packages (https://en.sfml-dev.org/forums/index.php?topic=17060.0). 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
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on December 23, 2017, 08:28:10 pm
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 (https://github.com/SFML/SFML/issues/758), #937 (https://github.com/SFML/SFML/issues/937)) and feel free to discuss potential adjustments before creating a pull request, if you're interested in contributing. :)
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Laurent on December 23, 2017, 09:31:19 pm
Quote
So is it "just" a matter of doing it
This. "Modern CMake" is so much better than what we have.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on December 23, 2017, 09:53:33 pm
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 (https://github.com/SFML/SFML/issues/758), #937 (https://github.com/SFML/SFML/issues/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.

Quote
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 :D
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Laurent on December 23, 2017, 10:17:43 pm
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 ;D
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on December 24, 2017, 05:03:27 pm
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. :)
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on December 29, 2017, 04:22:18 pm
Oh well, looks like time has passed since the last discussions. :)
Does it mean there is no reason anymore to keep CMake 2.8 ?
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Laurent on December 29, 2017, 06:55:39 pm
As far as I'm concerned, we can switch to CMake 3.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on December 29, 2017, 07:25:04 pm
I sent a mail off to the SFML Debian package maintainer to get his insight on the state of CMake versioning.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on December 30, 2017, 01:40:42 am
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.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on December 30, 2017, 09:32:16 am
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.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on December 30, 2017, 02:11:27 pm
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)
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on January 03, 2018, 04:02:17 am
Just found James' response in my junk mail:

Quote
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.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on January 04, 2018, 12:41:00 am
Awesome! Might be my next PR after the 2 current ones if nobody else takes care of it in the meantime :D
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on January 11, 2018, 11:21:35 pm
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.
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: eXpl0it3r on January 11, 2018, 11:30:44 pm
Why a separate PR? Can't you just bump it in your config PR?
Title: Re: Why is SFML still using CMake 2.8 ?
Post by: Ceylo on January 11, 2018, 11:37:24 pm
It's getting too big for my taste so if improvements can be merged little by little they'll also be available earlier. Also the more changes I keep in the config PR, the higher the probability of conflict with other changes merged to master.