Fixed CMake configuration issue with EGL and GLES and wrong include header order for EGL

[eXpl0it3r]

Description

This fixes the issue reported on the forum and a fix proposed with #1539.
However this fix follows a different solution than the one outlined in the forum by @LaurentGomila.
Silently ignoring duplicated target definitions isn't really a good solution, as it would support calling the sfml_find_package whenever and as many times as one sees fit, instead of being explicit about when to use it and fail if it's used when it's not needed.
And as it turns out EGL isn't even needed in the graphics module, so we don't have to search for it there anyways.

Additionally, this also fixes an include order issue where Xlib's None macro would conflict with SFML's None window style.

Sadly, I couldn't link SFML's graphics module on my Raspberry Pi from the first generation as it doesn't support the needed OpenGL ES 1.0 OSE extensions for the framebuffer.

Tasks

• Tested on Linux

• Tested on Windows

• "Tested" on Raspberry Pi (1st Gen)

• Builds on macOS

• Builds on iOS

• Builds on Android

How to test this PR?

Build SFML on an EGL/GLES platform with cmake -DSFML_OPENGL_ES=ON.

[LaurentGomila]

Silently ignoring duplicated target definitions isn't really a good solution, as it would support calling the sfml_find_package whenever and as many times as one sees fit, instead of being explicit about when to use it and fail if it's used when it's not needed.

Maybe I just don't get your reasoning, but to me it's more intuitive to call sfml_find_package whenever you need to find a package, than checking other modules to see if, by chance, they haven't already done it.

[eXpl0it3r]

The reasoning is mostly to be aware of the dependency chain so you don't build on false assumptions or cause accidental wrong behavior further down the line.

[LaurentGomila]

There's no dependency chain, both modules link to the same library, independently. It's a private detail that other modules don't have to know about (otherwise it would be linked publicly and automatically forwarded by CMake).

If one day sfml-window doesn't need OpenGL anymore, sfml-graphics will still need it -- with my solution it would still work, with yours it would break.

Admittedly, I didn't follow the reason why this change was reverted, so I may be missing something important 😄

[binary1248]

EGL should never have been required from sfml-graphics since it is only required for context handling which is dealt with exclusively in sfml-window, hence the dependency of sfml-graphics on sfml-window. Silencing the output would have masked this error.

Sure... one can make the argument that some system libraries might be required from multiple SFML modules, but currently we are in the nice situation that SFML's dependencies on external libraries is pretty well structured and not spread out all over the place. In order to keep it this way we need signals that we can rely on when we might be doing something potentially wrong. If something really can't be implemented in another way then we can make an exception for it, but I would rather not make the exception into the rule.

[eXpl0it3r]

@JonnyPtn or @Ceylo could you also take a look at this?

[JonnyPtn]

Don't have a linux machine to test the xlib stuff on right now, but looks mostly OK to me. I don't really have an opinion on whether it's better to call find_package more than once.

[F41sc4]

I was able to compile SFML 2.5.1 on Linux (Raspbian on RPI 3B+) using this branch (bugfix/config-gles-egl), however, if I enable SFML_BUILD_TEST_SUITE or SFML_BUILD_EXAMPLES on CMake, the project won't compile (fails on "make" stage).

I doubt that the modifications made by @eXpl0it3r on CMake files directly affected how the SFML libraries work, but for some reason it's not compiling.

Since this was accepted to 2.6.0, It'd worth taking a look at this before merging.

In both cases, SFML_OPENGL_ES is enabled, since this was my intent on building SFML from source on RPI 3B+.

If you need specific outputs from the building process, just let me know.

[eXpl0it3r]

@F41sc4 can you provide the error when building the test suits/examples?
I assume that without this PR, you don't even get as far, correct?

[F41sc4]

Lucas, I've just disabled EXAMPLES ans TEST_SUITE, so it compiles correctly. It just doesn't compile with the mentioned CMake options enabled. I prepared different build directories for each options to analyze them separately. I will have a chance soon to post the outputs here. Just don't have the machine available now. Thanks for replying. I will be in touch. Em seg, 27 de mai de 2019 03:49, Lukas Dürrenberger < notifications@github.com> escreveu:

…

@F41sc4 <https://github.com/F41sc4> can you provide the error when building the test suits/examples? I assume that without this PR, you don't even get as far, correct? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1577?email_source=notifications&email_token=AMFSA5ZMUIT3Z62VYZ3JSX3PXN763A5CNFSM4HFYTFY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWI572Y#issuecomment-496099307>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMFSA5ZMLWERX5CU3NY5HPTPXN763ANCNFSM4HFYTFYQ> .

[F41sc4]

@lukas-w what do you mean by "PR"?

If I use the current "master" branch, yes, I can't get too far due to the CMake "bug" that gave origin to this issue.

I was able to compile SFML 2.5.1 (using the "bugfix/config-gles-egl" branch) on Raspberry PI 3B+ with both SFML_BUILD_TEST_SUITE and SFML_BUILD_EXAMPLES enabled, but SFML_OPENGL_ES disabled.

Considering SFML_OPENGL_ES enabled, I do the following:

I configure the project using "Unix Makefiles" generator (enabled through cmake-gui utility), enable SFML_BUILD_TEST_SUITE and SFML_OPENGL_ES, then "Generate". I go to the build directory I chose and run "make", as usual. So I got the following error when it tries linking test-sfml-graphics executable:

...
[ 92%] Building CXX object test/CMakeFiles/test-sfml-graphics.dir/src/TestUtilities/GraphicsUtil.cpp.o [ 93%] Linking CXX executable test-sfml-graphics ../lib/libsfml-graphics.so.2.5.1: undefined reference to glFramebufferTexture2DOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenRenderbuffersOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenerateMipmapOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glCheckFramebufferStatusOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glBlendEquationSeparateOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glBindFramebufferOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glRenderbufferStorageOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glDeleteRenderbuffersOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glFramebufferRenderbufferOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glBindRenderbufferOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glDeleteFramebuffersOES'
../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenFramebuffersOES' ../lib/libsfml-graphics.so.2.5.1: undefined reference to glBlendFuncSeparateOES'
collect2: error: ld returned 1 exit status
test/CMakeFiles/test-sfml-graphics.dir/build.make:149: recipe for target 'test/test-sfml-graphics' failed
make[2]: *** [test/test-sfml-graphics] Error 1
CMakeFiles/Makefile2:399: recipe for target 'test/CMakeFiles/test-sfml-graphics.dir/all' failed
make[1]: *** [test/CMakeFiles/test-sfml-graphics.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2`

Right now, I'm doing the same test with SFML_BUILD_EXAMPLES and SFML_OPENGL_ES both enabled (disabled SFML_BUILD_TEST_SUITE to try to isolate the problem). I'll be providing the output next.

[F41sc4]

As mentioned before, with SFML_OPENGL_ES and SFML_BUILD_EXAMPLES enabled, I get a build error when it tries linking "opengl" executable:

Scanning dependencies of target opengl [ 93%] Building CXX object examples/opengl/CMakeFiles/opengl.dir/OpenGL.cpp.o [ 94%] Linking CXX executable opengl ../../lib/libsfml-graphics.so.2.5.1: undefined reference toglFramebufferTexture2DOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenRenderbuffersOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenerateMipmapOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glCheckFramebufferStatusOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glBlendEquationSeparateOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glBindFramebufferOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glRenderbufferStorageOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glDeleteRenderbuffersOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glFramebufferRenderbufferOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glBindRenderbufferOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glDeleteFramebuffersOES'
../../lib/libsfml-graphics.so.2.5.1: undefined reference to glGenFramebuffersOES' ../../lib/libsfml-graphics.so.2.5.1: undefined reference to glBlendFuncSeparateOES'
collect2: error: ld returned 1 exit status
examples/opengl/CMakeFiles/opengl.dir/build.make:98: recipe for target 'examples/opengl/opengl' failed
make[2]: *** [examples/opengl/opengl] Error 1
CMakeFiles/Makefile2:781: recipe for target 'examples/opengl/CMakeFiles/opengl.dir/all' failed
make[1]: *** [examples/opengl/CMakeFiles/opengl.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
`

If you need further information about the setup, just let me know.

CMake version is 3.7.2 (provided by Raspbian stable/stretch).

[lukas-w]

@lukas-w what do you mean by "PR"?

I think you meant to tag @eXpl0it3r here.

[F41sc4]

Sure, my bad. Sorry, @lukas-w

[eXpl0it3r]

Superseded by #1603