Linking dependencies

[Laurent]

If I do it I think I'll support all OSes, even if static linking is discouraged on Linux I can't provide a half-implemented feature.

All non-default libraries will be included, i.e. everything that I have to link myself for SFML. So yes, winmm will be part of it.

I initially wanted to put them in SFML_LIBRARIES directly, but you're right, if someone wants to use its own version of a library, it will become tricky

[binary1248]

SFML should follow what other libraries already do with their _LIBRARIES variable in CMake... just specify the libraries actually provided by SFML. Nobody tosses all of their dependencies into their _LIBRARIES variable, otherwise you would see OpenGL and the rest of the operating system libraries in scripts like FindGLUT.cmake as an example. I'm guessing that it is convention and already expected that the user will link to the correct operating system libraries on their own.

When SFML looks for it's dependency packages, on Linux (and OS X?) it works perfectly, since everything is installed in a central location and whatever the user would want to use, they would have already installed as a package anyway, so the issue of the user wanting to use their own version of whatever library doesn't exist.

The problem on Windows is that CMake has no idea where the user might be hiding their libraries, so without explicitly asking or getting the information from a special environment variable, it has to assume there is none available. In this case, if the user wanted to use their own version of a library, they would simply specify it to CMake using the provided variables when configuring SFML.

If a user is dumb enough to use 2 different library versions, or let SFML use the "default" one and then use their own in their project, then they really can't complain that it won't work. On the other hand, since some distributions of MinGW come with e.g. GLEW and freetype installed into the compiler's directories already, SFML should try harder to use those instead of it's own. I have one of these distributions, and the Find scripts still prefer to use the libraries provided with SFML instead of the ones in my compiler folders. Good thing I don't use them in my projects... otherwise who knows what would happen.

[Wizzard]

Using MinGW I did the following setup:

Defines
GLEW_STATIC
SFML_STATIC
UNICODE

Libraries
sfml-audio-s
sfml-graphics-s
sfml-network-s
sfml-window-s
sfml-system-s
sndfile
openal32
jpeg
glew
freetype
ws2_32
gdi32
opengl32
winmm

It compiles and runs just fine - but I might be doing too much

[eXpl0it3r]

It compiles and runs just fine - but I might be doing too much

If you link all SFML modules then the list seems to be the same as mine.

[Nexus]

Laurent, can we help somehow with the FindSFML module?

I'm currently figuring out how to handle the paths to the dependencies the best way. Many of the binaries are installed in the directory ${SFML_ROOT}/lib, however some (such as OpenGL) are provided by the operating system. Would it be necessary to refer to the corresponding CMake modules?

On Linux, I'm not sure at all -- there may be a lot of system libraries required (similar to winmm.lib on Windows). Let alone OS X...

[Laurent]

We should definitely find a solution quickly, I'm currently stuck with CSFML which is exactly in this case: it links SFML statically and uses FindSFML.cmake

But it's complicated. The options are:

1. FindSFML.cmake provides a list of libraries names, it's up to the user to find them -> very inconvenient
2. FindSFML.cmake finds the dependencies and provides full paths -> what if user wants to use its own version of a library?
3. Don't do anything, like all other libraries seem to do and let the user handle dependencies on its own -> really inconvenient, especially in case of multi-platform programs

[Nexus]

2. FindSFML.cmake finds the dependencies and provides full paths -> what if user wants to use its own version of a library?

This looks like the way to go.

My suggestion: We define a SFML_DEPENDENCIES variable with the full paths to all dependencies. I could write a prototype, but I'm uncertain about the points I mentioned in the last post.

For more customization, it would still be possible to define single variables such as SFML_DEPENDENCY_GLEW, so SFML_DEPENDENCIES would just be a list of them. But at the moment, it's important that linking works again

[binary1248]

Just give the user a choice. If they don't care, they can let SFML handle everything. If they care (like me) they add everything themselves. If they do both, they burn .

[Nexus]

Actually, we could set SFML_DEPENDENCIES to the default paths of all dependencies, and the user would then still be free to edit it (very easy in the CMake GUI). This is already much better than the status quo, where everybody has to rewrite the non-trivial CMake code to find the correct dependencies.

This approach is a problem, if the user wants to configure SFML programmatically from another script that calls CMake. He would then have to painfully extract and replace the paths he likes that's why we can think about the single variables later...

[eXpl0it3r]

Yes, if the users gets the chance to only change a variable rather than having to change CMake code itself, then this sounds like a good way.
People that want to automate things and use "non-standard" libraries, should be able to write some small CMake magic, besides CMake still kind of encourages such hacks...

We should definitely find a solution quickly, I'm currently stuck with CSFML which is exactly in this case: it links SFML statically and uses FindSFML.cmake

I've noticed, since I can't build my Nightly Builds for CSFML either.

[Laurent]

Or maybe SFML could try to find the libraries, except for those that are already defined? In this case SFML would use what's already defined, this way the user would just have to find GLEW or whatever before finding SFML; it could even work automatically (FindGLEW.cmake does problably nothing if GLEW_FOUND, GLEW_LIBRARY etc are already defined).

[Nexus]

That's a good idea.

I'm not sure if you can rely on the other CMake modules to do nothing if you request them (i.e. to expect them not to override any settings). If not, you could check whether an output variable is already defined (-> command reference):

if(DEFINED GLEW_FOUND)

[Laurent]

There's one problem though: not all these libraries have a standard FindXxx.cmake script, with well-known variables to check. Some of them use a home-made script, and some others such as system libraries are not searched at all, their name is directly used in the target_link_libraries command. However I don't think users will want to link another version of the system libraries

So there would be a problem only for GLEW and libsndfile.

[Nexus]

At the moment, you somehow find them too, can't you apply the same approach again?

Maybe it will be necessary to handle corresponding variables to allow customization...

[Laurent]

I've done something. Now FindSFML.cmake provides a list of all dependencies (full path to libraries) per component or globally.

Tested on Windows (VC++ and gcc), not on Linux nor OS X. Linux may require some adjustements, and OS X is probably totally broken; but hopefully nobody will try to link SFML statically on these platforms until I get more help

Customization of one or more paths is probably not straight-forward with this way of doing things, but at least things can work out-of-the box again.