Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Linking dependencies  (Read 61612 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Linking dependencies
« Reply #60 on: October 18, 2013, 09:49:36 pm »
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 :-\
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Linking dependencies
« Reply #61 on: October 19, 2013, 02:15:54 am »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Wizzard

  • Full Member
  • ***
  • Posts: 213
    • View Profile
Re: Linking dependencies
« Reply #62 on: October 19, 2013, 11:53:28 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
AW: Re: Linking dependencies
« Reply #63 on: October 20, 2013, 08:03:39 am »
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. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Linking dependencies
« Reply #64 on: October 24, 2013, 04:55:35 pm »
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...
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Linking dependencies
« Reply #65 on: October 24, 2013, 05:05:34 pm »
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 ;D

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
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Linking dependencies
« Reply #66 on: October 24, 2013, 05:11:52 pm »
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 ;)
« Last Edit: October 24, 2013, 05:13:54 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Linking dependencies
« Reply #67 on: October 24, 2013, 05:16:13 pm »
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 ;D.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Linking dependencies
« Reply #68 on: October 24, 2013, 05:28:00 pm »
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 :P that's why we can think about the single variables later...
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Linking dependencies
« Reply #69 on: October 24, 2013, 06:02:57 pm »
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 ;D
I've noticed, since I can't build my Nightly Builds for CSFML either. ;D
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Linking dependencies
« Reply #70 on: October 24, 2013, 08:59:51 pm »
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).
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Linking dependencies
« Reply #71 on: October 25, 2013, 08:19:58 am »
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)
« Last Edit: October 25, 2013, 08:27:32 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Linking dependencies
« Reply #72 on: October 25, 2013, 08:26:39 am »
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 ;D

So there would be a problem only for GLEW and libsndfile.
« Last Edit: October 25, 2013, 08:29:28 am by Laurent »
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Linking dependencies
« Reply #73 on: October 25, 2013, 08:28:30 am »
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...
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Linking dependencies
« Reply #74 on: November 04, 2013, 10:47:13 pm »
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.
Laurent Gomila - SFML developer

 

anything