Added GL to SFML Dependencies

[Nopey]

because SFML renderer uses glScissor, and will not compile (for me) without linking to GL

[eXpl0it3r]

This is already done by the FindSFML.cmake script:. Not sure why it doesn't work for you.

What OS did you test this with? What version of FindSFML.cmake did you use?

[Nopey]

Figured it out. My parent project added a FindSFML.cmake module that didn't link to GL. (Fixing that now) Weird that the added modules effect gwork through the externalproject_add call. I still think that because the Renderer calls an OpenGL function directly that it should add GL to the linker, whether or not FindSFML.cmake depends on OpenGL.

[billyquith]

Which platform are you reporting this on?

I still think that because the Renderer calls an OpenGL function directly that it should add GL to the linker, whether or not FindSFML.cmake depends on OpenGL.

All of the samples use the same cmake config. The link options are set in the config. If a renderer has dependencies they are added here.

https://github.com/billyquith/GWork/blob/gwork/source/samples/CMakeLists.txt#L42

SFML2 uses OpenGL on all platforms and does include it in the dependencies, as @eXpl0it3r says.

[Nopey]

According to https://www.sfml-dev.org/tutorials/2.3/window-opengl.php

You will then need to link your program to the OpenGL library. Unlike what it does with the headers, SFML can't provide a unified way of linking OpenGL

This is specifically for when you want to use OpenGL in a window, that you'll need to link it. It implies SFML doesn't actually need OpenGL to be linked onto your project until you use a gl function.

[eXpl0it3r]

SFML obviously uses OpenGL internally.

Now if you build shared libs version of SFML, then SFML will link to OpenGL, but OpenGL won't be automatically available to use in your project. So yes, you need to link OpenGL for your project if you use OpenGL.

However, when you build SFML statically, all its dependencies have to be linked into your final application, thus the SFML_DEPENDENCIES will list OpenGL there and you don't have to add it yourself explicitly.

So I guess OpenGL does need to be added when linking SFML as shared libs, if GWork uses custom OpenGL code.

[Nopey]

Heres the GL call from SFML2.cpp that I mentioned before https://github.com/billyquith/GWork/blob/gwork/source/platform/renderers/SFML2/SFML2.cpp#L97

[billyquith]

This is specifically for when you want to use OpenGL in a window, that you'll need to link it. It implies SFML doesn't actually need OpenGL to be linked onto your project until you use a gl function.

I don't think this assumption is correct. I can see how you would make it though. The SFML cmake config only finds the OpenGL libraries to link to if you use the "window" component. From this you might assume that you only need to link to OpenGL if you use a window component. However, if you look through the source code, you can see the graphics module uses OpenGL. This is therefore a problem with the SFML documentation. For this reason I don't intend to change Gwork to fix this. The samples already provided demonstrate how to set up a project. I think in your higher level project you need to add the "window" component, even if you are not using it. This detail could be added to the Gwork docs to help.

[eXpl0it3r]

The SFML cmake config only finds the OpenGL libraries to link to if you use the "window" component. From this you might assume that you only need to link to OpenGL if you use a window component. However, if you look through the source code, you can see the graphics module uses OpenGL. This is therefore a problem with the SFML documentation

You can not use the graphics module without the window module, they depend on each other, thus when you use the graphics module, you already get the OpenGL dependency through the window module.

The important part has already been mentioned above:

If you build shared libs version of SFML, then SFML will link to OpenGL, but OpenGL won't be automatically available to use in your project. So yes, you need to link OpenGL for your project if you use OpenGL.

[billyquith]

thus when you use the graphics module, you already get the OpenGL dependency through the window module.

If you only specify the graphics module when using FindSFML does it automatically add the window module as a dependency?

[eXpl0it3r]

Looking at the FindSFML.cmake, I can't find such a check. It will simply iterate over all the given components. Then again it's in the users responsibility to link/request all the right libraries.

[billyquith]

Looking at the FindSFML.cmake, I can't find such a check. It will simply iterate over all the given components. Then again it's in the users responsibility to link/request all the right libraries.

I can't find it either. The SFML docs seem to suggest otherwise, as @Nopey is arguing. I can see the reason for the confusion, reading the SFML docs. The wording could be better. It does, generally have pretty good docs, I don't want to be too hard! Better than GWEN/Gwork's!

Anyway I think we have a solution to this: the SFML docs are bit misleading/unclear, but if we specify both "graphics" and "window" and link to the SFML dependencies then everything works. I don't think we need to modify Gwork.

[eXpl0it3r]

Either I'm missing what the discussion was really about or you are mixing multiple topics.

SFML component/module dependency

The graphics module depends on the window module which depends on the system module. As such when you call find_package(SFML COMPONENTS graphics) you also have to specify window and system, i.e. find_package(SFML COMPONENTS graphics window system). This dependency is AFAIK well documented and people rarely get confused out this.

SFML third-party dependencies

SFML uses OpenGL and various other third-party libraries. The linking of these libraries is different for when you build SFML as static or as dynamic library.

• Shared: The third-party libraries get linked directly into the the SFML shared libraries (.so / .dll) and are not exposed to the end-user. For all the end-user knows, SFML comes as a complete package.
• Static: The third-party libraries are not linked at this stage. The end-user wants to have all the libraries built into their application. By magically hacking the third-party libs into the SFML libs (as SFML used to do ages ago), one would most certainly run into troubles as soon as the end-user wants to use the same third-party library in their own code, because then you'd have each a different version of the third-party library in the user application and in the SFML libs. Instead the static libraries get all linked in the end-user application, this means that even SFML's dependencies (i.e. third-party libraries) need to be linked in the user project.

End user wants to use third-party library as well

Now we finally come to the problem, as much as I understood it, reported here. GWork is using glScissor, i.e. an OpenGL function and OpenGL is a third-party library of SFML, as such you as end user of SFML has to link against OpenGL yourself. But as before we have scenarios here:

• Shared: SFML doesn't expose its dependencies. Note the ${SFML_DEPENDENCIES} only gets populated if you're using SFML as static library. Whether you specify ${SFML_DEPENDENCIES} or not, as long as you're link SFML dynamically, you have to ensure that you link to the third-party library (i.e. OpenGL).
• Static: SFML doesn't link its dependencies, but provides them all listed in ${SFML_DEPENDENCIES}, which you have to link against if you intend to use SFML as static library. Since OpenGL is not only a third-party library of GWork, but also one of SFML, the dependency list does include OpenGL. You don't necessarily have to manually link OpenGL.

I hope this clears things up. 😉