Replace FindSFML.cmake with SFMLConfig.cmake #1335

Ceylo · 2017-12-30T12:37:06Z

TODO list:

Have config file generated on all platforms
Support debug/release config
Have no absolute path in generated config files on Linux / Windows / macOS / iOS? / Android?
Export internal dependencies in case of static build (ie. remove the need for SFML_DEPENDENCIES)
Support for REQUIRED/QUIET options of find_package()
Framework install path
SFML_DOC_DIR
Remove FindSFML.cmake once SFMLConfig supports everything from it
Exhaustive testing! ==> see https://en.sfml-dev.org/forums/index.php?topic=23676.msg161479#msg161479

Out of scope:

Compatibility with split Linux packages
Support for components

=============

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.

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) of course without any FindSFML.cmake:

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.

If you want to look at what the generated config looks like for now:
http://yalir.org/files/SFML/
It gets installed in /usr/local/lib/cmake/SFML by default.

References

https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages
https://cmake.org/cmake/help/latest/command/find_package.html
https://cmake.org/cmake/help/latest/command/export.html
https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html
master...SrTobi:support-config-file-packages

Related issues

#758
#937

Ceylo · 2017-12-30T12:40:47Z

CMakeLists.txt

@@ -69,9 +69,6 @@ set(VERSION_MAJOR 2)
 set(VERSION_MINOR 4)
 set(VERSION_PATCH 2)

-# add the SFML header path
-include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)


to be "exportable", this needs to be defined on targets, not globally, thus https://github.com/SFML/SFML/pull/1335/files#diff-031c6047a0f4c227a313b7b2f3b77219R141

Ceylo · 2017-12-30T12:43:05Z

cmake/Macros.cmake

@@ -2,13 +2,14 @@ include(CMakeParseArguments)

 # add a new target which is a SFML library
 # ex: sfml_add_library(sfml-graphics
-#                      SOURCES sprite.cpp image.cpp ...
-#                      DEPENDS sfml-window sfml-system
-#                      EXTERNAL_LIBS opengl freetype ...)


Distinction was only for internal vs external dependencies? (linking against a lib already creates a dependency)
I removed these because it doesn't allow specifying dependency by dependency if that said dependency is PRIVATE or PUBLIC

Ceylo · 2017-12-30T12:43:35Z

cmake/Macros.cmake

    # add the install rule
-    install(TARGETS ${target}
+    install(TARGETS ${target} EXPORT SFMLConfigExport


The KEY to having targets exported to the final config file
Reused in https://github.com/SFML/SFML/pull/1335/files#diff-80cb5bd89215157ada070906e35cadbb

Ceylo · 2017-12-30T12:45:25Z

cmake/Macros.cmake

+    # the first one is for the local package and the second one is for the installed package
+    target_include_directories(${target} PUBLIC
+                               $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
+                               $<INSTALL_INTERFACE:include>)


The only PUBLIC property right now

Ceylo · 2017-12-30T12:46:16Z

cmake/export/SFMLConfig.cmake

@@ -0,0 +1 @@
+include("${CMAKE_CURRENT_LIST_DIR}/SFMLTargets.cmake")


From https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file

Ceylo · 2017-12-30T13:05:58Z

cmake/export/SFMLConfigExport.cmake

@@ -0,0 +1,26 @@
+


mainly from https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages

Ceylo · 2017-12-30T13:07:32Z

src/SFML/Graphics/CMakeLists.txt

-    list(APPEND GRAPHICS_EXT_LIBS z)
-endif()
-list(APPEND GRAPHICS_EXT_LIBS ${FREETYPE_LIBRARY})
+target_include_directories(sfml-graphics PRIVATE ${FREETYPE_INCLUDE_DIRS})


Note that this one was previously duplicated line 110 and 122

Ceylo · 2017-12-30T13:08:43Z

src/SFML/Audio/CMakeLists.txt

-add_definitions(-DOV_EXCLUDE_STATIC_CALLBACKS) # avoids warnings in vorbisfile.h
-add_definitions(-DFLAC__NO_DLL)
+# define the sfml-audio target
+sfml_add_library(sfml-audio


target needs to be defined before using target_link_libraries(), target_include_directories() and target_compile_definitions(), so moved from below

LaurentGomila · 2017-12-30T15:28:26Z

Amazing work, thanks 👍

I know very little about modern CMake usage, but what I see looks ok. We should now test it under various scenarios (static/dynamic link, on all OSes).

this will allow specifying which dependencies must be public in case of static linking

What exactly does that mean? Will CMake now automatically export the private dependencies in case of static linking, or does it require additional work? In any case, we no longer need SFML_DEPENDENCIES, right?

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

Should be done, since the dependency does exist.

MarioLiebisch · 2017-12-30T16:04:30Z

Didn't dig too deep into the changes, but with the branch as-is, sfml-main won't build, since its include directories aren't set (and therefore won't find SFML/Config.hpp).

You're basically missing this:

# set the include directory
target_include_directories(sfml-main PUBLIC
                               $<BUILD_INTERFACE:${PROJECT_SOURCE_DIR}/include>
                               $<INSTALL_INTERFACE:include>)

from sfml-main's CMakeLists.txt.

Also are you sure about the location of the SFMLConfig.cmake and the other files? I thought they'd have to be placed directly in lib or am I confusing it with PkgConfig?

Ceylo · 2017-12-30T16:07:48Z

I know very little about modern CMake usage, but what I see looks ok. We should now test it under various scenarios (static/dynamic link, on all OSes).

The most important part is correctly defining which target properties have PRIVATE, PUBLIC or INTERFACE visibility. Are you familiar with it?
Basically PRIVATE properties are used only when building the target.
PUBLIC properties are used when building the target and by targets that depend on your target.
INTERFACE properties are used only by targets that depend on your target.

And in these properties you can define include directories, libraries to link or preprocessor definitions.

What exactly does that mean? Will CMake now automatically export the private dependencies in case of static linking, or does it require additional work? In any case, we no longer need SFML_DEPENDENCIES, right?

It will, at least that's what I want. But it's not done yet with current changes. And yes SFML_DEPENDENCIES won't be needed anymore if I get it to work. Will update the PR when it's ready.

Should be done, since the dependency does exist.

Right, will update when it's done

Ceylo · 2017-12-30T16:14:11Z

Didn't dig too deep into the changes, but with the branch as-is, sfml-main won't build, since its include directories aren't set (and therefore won't find SFML/Config.hpp).

Indeed. Didn't do it yet as it's not needed on macOS, because I wanted feedbacks before going further. Will fix it.

Also are you sure about the location of the SFMLConfig.cmake and the other files? I thought they'd have to be placed directly in lib or am I confusing it with PkgConfig?

There are several possible paths, see https://cmake.org/cmake/help/latest/command/find_package.html

"Each entry is meant for installation trees following Windows (W), UNIX (U), or Apple (A) conventions:"

<prefix>/                                                       (W)
<prefix>/(cmake|CMake)/                                         (W)
<prefix>/<name>*/                                               (W)
<prefix>/<name>*/(cmake|CMake)/                                 (W)
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/                  (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/                        (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/          (U)
<prefix>/<name>*/(lib/<arch>|lib|share)/cmake/<name>*/          (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/                (W/U)
<prefix>/<name>*/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/  (W/U)
<prefix>/<name>.framework/Resources/                    (A)
<prefix>/<name>.framework/Resources/CMake/              (A)
<prefix>/<name>.framework/Versions/*/Resources/         (A)
<prefix>/<name>.framework/Versions/*/Resources/CMake/   (A)
<prefix>/<name>.app/Contents/Resources/                 (A)
<prefix>/<name>.app/Contents/Resources/CMake/           (A)

Still need to figure out where it'll be located in the end. It's probably not portable on this part right now.

eXpl0it3r · 2017-12-30T16:27:59Z

I initiated the CI builds, checkout the build logs (Config.hpp can't be found).

MarioLiebisch · 2017-12-30T16:28:33Z

Which is exactly what I've stated above. ;)

Ceylo · 2017-12-31T16:31:48Z

Build is fixed for sfml-main, everything builds fine locally on Windows (VS2017 32bits).
The dependencies between SFML modules are now public so examples like VOIP only need to depend on sfml-network and sfml-audio, no need to specify sfml-system. The same applies to external projects that will use find_package(SFML) and depend on a SFML module.

I ran the install step with the Debug/Release configuration and did a find_package(SFML) without any FindSFML.cmake and it did work on Windows, with the correct lib depending on selected configuration (Debug/Release).

There doesn't look to be any absolute path in the generated config file on Windows, which is nice for making releases. On the contrary for now the config file generated on macOS has absolute paths (/Library/Frameworks). To be fixed.

Still need to support static builds, most likely the hardest part because of the need to expose internal dependencies.

And I don't know yet what to do about components handling...

One important note

I changed a bit how the sfml-main library is created. Instead of custom add_library() and properties, it's created like any other SFML library : with suffix for debug / static, and with pdb next to the generated .lib file. The only customization I kept is that it always remains a static lib, whatever the value of BUILD_SHARED_LIBS.

MarioLiebisch · 2017-12-31T16:49:03Z

Nice. I'd say absolute paths aren't that bad for now. Wouldn't they be the same on any machine anyway? No experience with Frameworks, but from my understand they're supposed to sit in that specific directory?

MarioLiebisch · 2017-12-31T16:56:32Z

New revision is building fine for me on Windows. Do we even have to keep (and therefore maintain) FindSFML.cmake? Or should it be deprecated/removed altogether? From my understanding we wouldn't need both. Or is there some minimum version requirement higher than using a Find….cmake file?

Ceylo · 2017-12-31T17:16:40Z

Nice. I'd say absolute paths aren't that bad for now. Wouldn't they be the same on any machine anyway? No experience with Frameworks, but from my understand they're supposed to sit in that specific directory?

It depends on what you want to do. Currently FindSFML.cmake allows finding SFML in standard paths or in custom paths if you set SFML_ROOT. I don't see any reason to restrict the benefits of CMake config files to standard installations only.

Consider for example where you want to make sure that the package you're creating for your program is self-contained. In that case you don't want to have SFML installed in standard paths. You can also want to keep standard paths clean, or don't have admin rights, etc.

New revision is building fine for me on Windows. Do we even have to keep (and therefore maintain) FindSFML.cmake ? Or should it be deprecated/removed altogether? From my understanding we wouldn't need both. Or is there some minimum version requirement higher than using a Find….cmake file?

I'm always for keeping a simple and unique way to do things. But I don't think I'm the one to choose this for SFML :)
As for the minimum requirement.. is SFML's CI using CMake 2.8? If it does then it's ok, because I didn't add any conditional check for some CMake version.

Also I realize that currently existing FindSFML.cmake won't find the new sfml-main lib because of changed suffix. Is it acceptable to introduce such break in SFML 2.5?

MarioLiebisch · 2017-12-31T17:19:15Z

Also I realize that currently existing FindSFML.cmake won't find the new sfml-main lib because of changed suffix. Is it acceptable to introduce such break in SFML 2.5?

Do you mean the -s affix? Why not just overwrite it after defining the target? Or won't that work?

Ceylo · 2017-12-31T17:35:55Z

Do you mean the -s affix? Why not just overwrite it after defining the target? Or won't that work?

Yes the -s suffix, and yes overwriting does work. Committing, thanks.

Ceylo · 2017-12-31T17:59:04Z

@MarioLiebisch Do you know where sfml-graphics links against OpenGL ES libraries on Android? I can't find it on SFML/master and I broke link step of this module on Android: https://ci.sfml-dev.org/builders/android-armeabi-v7a-api13/builds/267/steps/compile/logs/stdio

I saw that you worked on Android support so asking you :)

MarioLiebisch · 2017-12-31T18:26:54Z

It used to be here:

https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/CMakeLists.txt#L126

but obviously got lost in the rewrite.

Ceylo · 2017-12-31T18:43:07Z

It's still there: https://github.com/Ceylo/SFML/blob/feature/CMakeTargetExport/src/SFML/Graphics/CMakeLists.txt#L124

And I don't think you pointed out the correct line, because in Config.cmake I see that Android uses OpenGL ES.

Ceylo · 2017-12-31T19:48:16Z

It seems like it was simply not set. But it previously worked because another signature of target_link_libraries() was used: https://cmake.org/cmake/help/latest/command/target_link_libraries.html?highlight=target_link_libraries#libraries-for-both-a-target-and-its-dependents

Which imported linkage for OpenGL ES from sfml-window target definition : https://github.com/SFML/SFML/blob/master/src/SFML/Window/CMakeLists.txt#L270

And it's no more the case with the explicit PRIVATE linkage (it was implicitly PUBLIC). Hopefully easy to fix :)

MarioLiebisch · 2017-12-31T21:05:59Z

But that's outside the SFML_OPENGL_ES branching starting in line 113.
Edit: Ah, missed the new commit.

Ceylo · 2018-01-02T11:18:37Z

Will be away till the end of the week so don’t be surprised if there’s no progress :)

Ceylo · 2018-03-23T22:06:38Z

@eXpl0it3r
I can't reproduce the issue about Doxygen. Here it generates the doc without any error log, and thus target succeeds. I'm using CMake 3.10.0, VS 2017 x64 generator and Doxygen 1.8.14. Didn't test with Doxygen 1.8.10 but if latest version works fine I guess it's ok. Does any of the CI builders generate the documentation? Can you test on your side with Doxygen 1.8.14?

As for where the PDB files go (ie. not next to libraries, and always in PREFIX/lib/Debug even for release builds), I checked and this is the same behavior as current master branch. Thus not going to change that for current PR.

The only difference I noticed about PDB files is that with my PR you now also get a PDB for sfml-main library.

All in all, if @LaurentGomila confirms expected behavior with find_package() and components, I guess current PR is still ok for merge. I'll just do a rebase against master to take into account latest commits.

LaurentGomila · 2018-03-24T07:47:49Z

CMake cache system actually prevents from doing that. Once a cache entry is set, setting it in CMake code won't change it, unless you force updating the cache (but then you discard user choice).

Yes, we musn't (can't) make one entry depend on the other. But what about using some default path if SFML_DEPENDENCIES_INSTALL_PREFIX is not set? Something relative to CMAKE_INSTALL_PREFIX.

set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

In case someone takes your minimal example as a reference: the SFML_DIR variable should always be defined as a user variable, not directly in the CMakeLists.txt file 😃

Did FindSFML.cmake previously work without any component given?

Not sure about the current behaviour. But that was just an idea anyway. Do you think it's worth investigating?

eXpl0it3r · 2018-03-24T10:47:34Z

CMake cache system actually prevents from doing that. Once a cache entry is set, setting it in CMake code won't change it, unless you force updating the cache (but then you discard user choice).

I thought so. For me it's just a different approach I'll have to take and define the prefix manually before clicking the configuration button. Unfortunately this will be an issue many people will fail to understand and we'll have to keep answering the same question. IMHO on Windows it never makes sense to install the dependencies somewhere else, as such this is really inconvenient for Windows users.

Yes, we musn't (can't) make one entry depend on the other. But what about using some default path if SFML_DEPENDENCIES_INSTALL_PREFIX is not set? Something relative to CMAKE_INSTALL_PREFIX.

By default it will use CMAKE_INSTALL_PREFIX. The issue is, that CMAKE_INSTALL_PREFIX has to be defined before you hit the configuration button in the CMake UI, similar to how you'd specify it in the command line the first time you call it.

Would it be an option to not set the SFML_DEPENDENCIES_INSTALL_PREFIX as long as SFML_DEPENDENCIES_INSTALL_PREFIX wasn't set by the user and instead always use CMAKE_INSTALL_PREFIX? That way CMAKE_INSTALL_PREFIX will always be used, unless the user explicitly specifies SFML_DEPENDENCIES_INSTALL_PREFIX. And since it's needed on macOS you could set it there directly. Maybe that's too many if-elses?

I can't reproduce the issue about Doxygen.

Checked again on master branch, it exists as well with my Doxygen version. The reason I stuck with the version is because newer versions don't generate the nice HTML output we want, but that's not important for this PR. Works fine with the latest Doxygen, so let's forget about this.

As for where the PDB files go (ie. not next to libraries, and always in PREFIX/lib/Debug even for release builds), I checked and this is the same behavior as current master branch. Thus not going to change that for current PR.

Odd, I could swear the behavior was different in the past, but yet, I see the same thing on master branch, so let's align this with another PR.

Did FindSFML.cmake previously work without any component given?
Not sure about the current behaviour. But that was just an idea anyway. Do you think it's worth investigating?

I think it's okay the way it is right now. I just suspect again that people will get it wrong and we'll have to keep answering the same question.

My suggestion would be, something that I kind of wanted for a while, to have a dedicated tutorial not on how to build SFML, but on how to use SFML with CMake. That way we can hopefully answer a lot of questions and have a reference for people.

Also we need to make sure to update the existing CMake tutorial for these changes.

Ceylo · 2018-03-24T11:00:22Z

But what about using some default path if SFML_DEPENDENCIES_INSTALL_PREFIX is not set? Something relative to CMAKE_INSTALL_PREFIX.

This is a good point indeed. Dunno why I didn't do that just like for SFML_MISC_INSTALL_PREFIX. It's committed & pushed.

Would it be an option to not set the SFML_DEPENDENCIES_INSTALL_PREFIX as long as SFML_DEPENDENCIES_INSTALL_PREFIX wasn't set by the user and instead always use CMAKE_INSTALL_PREFIX?

So with the relative path it's just fixed, not need for all these ifs :)

In case someone takes your minimal example as a reference: the SFML_DIR variable should always be defined as a user variable, not directly in the CMakeLists.txt file 😃

I don't think this is always true. For example if you take a project that depends on SFML and wants to embed all their dependencies in their repo (let's say with Git LFS). Setting this variable in the main project allows having a repo ready to use just with a single clone. So it depends on whether the developer wants to embed its dependencies or let its users provide them.

Not sure about the current behaviour. But that was just an idea anyway. Do you think it's worth investigating?

Just to make sure I tried using current FindSFML.cmake with no component. The result is actually worse than what I thought... with no component, it always consider SFML to be found even when it's not :/

Found SFML .. in SFML_INCLUDE_DIR-NOTFOUND
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
SFML_INCLUDE_DIR
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/Demo
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/Demo
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/Demo
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/MinimalistDemo
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/MinimalistDemo
   used as include directory in directory C:/Users/Ceylo/Documents/sfeMovie/examples/MinimalistDemo

So no regression on that matter. As for investigating about support "no component given" case, I think this should be discussed and eventually changed later. I don't really have an opinion at the moment about whether this is a good idea.

My suggestion would be, something that I kind of wanted for a while, to have a dedicated tutorial not on how to build SFML, but on how to use SFML with CMake. That way we can hopefully answer a lot of questions and have a reference for people.

Currently I'd say that the best tutorial for this is the documentation in SFMLConfig.cmake file. But you have to find that file first, which is not quite obvious 😄 .

Also we need to make sure to update the existing CMake tutorial for these changes.

Do you mean more than #1335 (comment) ?

Also, can one of you relaunch the CI builds?

eXpl0it3r · 2018-03-24T12:12:31Z

Currently I'd say that the best tutorial for this is the documentation in SFMLConfig.cmake file. But you have to find that file first, which is not quite obvious

Could be more or less a 1:1 copy, I don't like spreading documentation across multiple places, especially since it's not an obvious place to look.

Do you mean more than #1335 (comment) ?

If that covers all, then that's good. 😊

Ceylo · 2018-03-24T13:05:01Z

Could be more or less a 1:1 copy, I don't like spreading documentation across multiple places, especially since it's not an obvious place to look.

A 1:1 copy would look weird to me. What about giving a link to SFMLConfig.cmake from SFML tutorials page? This way you can also make sure that the tutorial is consistent with what is shipped.

Ideally there would be some sort of Doxygen that generates formatted doc from the comments in CMake files, but I’m not aware of such tool.

By the way builds have finished now.

eXpl0it3r · 2018-03-26T22:05:12Z

Merged in fc655f5

Thanks for the exhaustive work and the pushing forward, really appreciated! 🎉

LaurentGomila · 2018-03-27T06:23:42Z

That was a huge task, and it was much awaited. Thank you very much 👍

Ceylo · 2018-03-27T18:58:42Z

Hooorrraaaaaay!!!!!!!
At last… :D

I would like to discuss with you about the PR process. Mainly about the testing part: it took almost 2 months between the day the PR was ready for testing and the day it got merged. This is way too long, even in the opensource world, and honestly if it always take this long I'm not gonna do other PRs. So I'd like to talk and find solutions with you.

Where can we do that? The PR comments don't feel like it's the right place, and on the forum (except maybe in section "SFML development" where I can't open topics) it's also too wide: this is mainly toward SFML development team & contributors.

mantognini · 2018-03-27T19:25:53Z

Yeah, this is a big step forward! I'm really happy for this top-quality contribution of yours! Thanks again.

I understand the feeling, and share your point of view. But the fact is that the team alone cannot handle everything, at least not quickly enough to keep the flow. The only solution I see is asking the community to test things out. Now, in the last few months, several people have joined the effort, and I thank them. Hopefully, this will attract more testers as well. In the meantime, if you have ideas on how to improve the overall process (doc, how-to's, issue handling,...) I feel it would best fit on the forum. I'm pretty sure a moderator will agree to move your thread in the right category. :)

eliasdaler · 2018-03-27T20:31:09Z

I think that people will be more likely to test if developers either provide detailed instructions on how to perform testing or make a test program if it's possible.

The easier it is for people to test, the more likely they're to do it.

Ceylo · 2018-03-27T22:15:11Z

I've opened https://en.sfml-dev.org/forums/index.php?topic=23841.0

Ceylo commented Dec 30, 2017

View reviewed changes

MarioLiebisch added feature m:config s:undecided labels Dec 30, 2017

MarioLiebisch added this to the 2.5 milestone Dec 30, 2017

Ceylo added 3 commits March 23, 2018 23:12

Modernize CMake files

4b8545b

Add support for SFMLConfig.cmake

ec89e92

Remove FindSFML.cmake

aa72ebf

Ceylo force-pushed the feature/CMakeTargetExport branch from 5d670c4 to aa72ebf Compare March 23, 2018 22:13

Make dependencies install directory relative to CMAKE_INSTALL_PREFIX

95bd21f

eXpl0it3r closed this Mar 26, 2018

SFML 2.5.0 automation moved this from Ready to Merged / Superseded Mar 26, 2018

eXpl0it3r referenced this pull request Mar 31, 2018

Remove FindSFML.cmake

09e24ad

This was referenced Apr 6, 2018

Install pkgconfig files by default on Linux/FreeBSD #1075

Closed

Wrong directory for example binaries #189

Closed

		@@ -0,0 +1 @@
		include("${CMAKE_CURRENT_LIST_DIR}/SFMLTargets.cmake")

Replace FindSFML.cmake with SFMLConfig.cmake #1335

Replace FindSFML.cmake with SFMLConfig.cmake #1335

Conversation

Ceylo commented Dec 30, 2017 • edited

References

Related issues

Ceylo Dec 30, 2017 • edited

Choose a reason for hiding this comment

Ceylo Dec 30, 2017 • edited

Choose a reason for hiding this comment

Ceylo Dec 30, 2017 • edited

Choose a reason for hiding this comment

Ceylo Dec 30, 2017

Choose a reason for hiding this comment

Ceylo Dec 30, 2017

Choose a reason for hiding this comment

Ceylo Dec 30, 2017

Choose a reason for hiding this comment

Ceylo Dec 30, 2017

Choose a reason for hiding this comment

Ceylo Dec 30, 2017

Choose a reason for hiding this comment

LaurentGomila commented Dec 30, 2017

MarioLiebisch commented Dec 30, 2017

Ceylo commented Dec 30, 2017

Ceylo commented Dec 30, 2017

eXpl0it3r commented Dec 30, 2017

MarioLiebisch commented Dec 30, 2017

Ceylo commented Dec 31, 2017 • edited

One important note

MarioLiebisch commented Dec 31, 2017

MarioLiebisch commented Dec 31, 2017

Ceylo commented Dec 31, 2017

MarioLiebisch commented Dec 31, 2017

Ceylo commented Dec 31, 2017

Ceylo commented Dec 31, 2017

MarioLiebisch commented Dec 31, 2017

Ceylo commented Dec 31, 2017

Ceylo commented Dec 31, 2017

MarioLiebisch commented Dec 31, 2017 • edited

Ceylo commented Jan 2, 2018

Ceylo commented Mar 23, 2018

LaurentGomila commented Mar 24, 2018 • edited

eXpl0it3r commented Mar 24, 2018

Ceylo commented Mar 24, 2018 • edited

eXpl0it3r commented Mar 24, 2018 • edited by ChrisThrasher

Ceylo commented Mar 24, 2018

eXpl0it3r commented Mar 26, 2018

LaurentGomila commented Mar 27, 2018

Ceylo commented Mar 27, 2018

mantognini commented Mar 27, 2018

eliasdaler commented Mar 27, 2018 • edited

Ceylo commented Mar 27, 2018

Ceylo commented Dec 30, 2017 •

edited

Ceylo Dec 30, 2017 •

edited

Ceylo Dec 30, 2017 •

edited

Ceylo Dec 30, 2017 •

edited

Ceylo commented Dec 31, 2017 •

edited

MarioLiebisch commented Dec 31, 2017 •

edited

LaurentGomila commented Mar 24, 2018 •

edited

Ceylo commented Mar 24, 2018 •

edited

eXpl0it3r commented Mar 24, 2018 •

edited by ChrisThrasher

eliasdaler commented Mar 27, 2018 •

edited