GLEW and not exporting the GLEW symbols in SFML

[binary1248]

Like I said, marking exported symbols is mandatory on Windows. So I've just implemented the same feature on Linux and OS X. So actually it now works consistently across compilers.

Please tell me you are not trying to duplicate the quirks of Windows on Linux . And I think you meant operating systems and not compilers . The fact that exported symbols have to be explicitly marked in Windows is already annoying enough. If you ask me it's much simpler the Linux way and keeping things "consistent" with Windows is a bad idea. They are the ones who follow the standards the least anyway.

And I still don't know how this thing relates to the initial problem. It's about shared SFML libs on Unix, whereas Mars_999 was talking about static libs and GLEW on Windows

Actually it has very little if anything at all to do with the initial problem . It was somewhat of a false deduction we made when trying to figure out why using GLEW in specific configurations didn't work. When I posted about it on SFGUI forums I was too lazy to dig out the logs again and was just recalling from memory. Now I have determined that the reason we don't use GLEW is because as you already stated using SFML as a static library and any other library (that also links to GLEW statically) as a dynamic library fails. Because this wasn't an option for us we opted to use GLee.

[Tank]

...and it's even something that can't be worked around in all cases, for example when using LGPL'd libs for projects that link statically to libraries mostly (i.e. link to SFML statically, but dynamically to another library using GLEW).

We're currently also thinking about adding options to our CMakeLists.txt that can be used to disable searching for and linking to external libraries (so that the end-user can decide which he wants to use and, that's also very important, which he doesn't want to search for through find_package() in SFGUI's CMakeLists.txt, for example when adding SFGUI as a submodule and building it within the project's tree so that it doesn't look for SFML if the project itself builds and links it in).

Those options can be declared ADVANCED so that it doesn't show up for "beginners" if you want to follow the "as simple and non-confusing as possible" approach. But for bigger projects with quite complex build pipelines it's very very useful.

Imho it's something that CMake doesn't do right, i.e. managing dependencies in a nice and clean way. But as there's no real alternative to CMake (I tried a lot of others and CMake works best in my opinion), there should be enough options to make everybody happy.

The same could be applied to SFML I guess. It's a little bit annoying to implement because it's boring, but it enhances the usage in big projects.

Besides of that, and I hope it's okay to write that in this thread (don't want to create X threads for connected topics), I'd like to ask if all SFML-related CMake options could be prefixed with "SFML_". I recently ran into the problem where multiple sub-projects used the same CMake cache variables. This can be easily circumvented by prefixes.

I truly like binary1248 and Tank feedback, they are experienced C++ programers who have a valuable point of view on SFML, but I would appreciate a little less aggressiveness and biased comments. I'm always open to discussions, there's no need to be so angry...

Don't take it too serious. You know us long enough to know how to treat our little flame comments – probably a side-effect of being nerdy sometimes. You're doing a good job generally, no doubts, so take our comments/feedback/flames as critique instead of insulting/similar.

[Laurent]

We're currently also thinking about adding options to our CMakeLists.txt that can be used to disable searching for and linking to external libraries (so that the end-user can decide which he wants to use and, that's also very important, which he doesn't want to search for through find_package() in SFGUI's CMakeLists.txt, for example when adding SFGUI as a submodule and building it within the project's tree so that it doesn't look for SFML if the project itself builds and links it in).

Since I always try to make things as simple as possible, I don't focus on this kind of advanced use cases, so it's hard for me to imagine solutions to them.
So I think you should try these modifications first, and if you're satisfied with them we can discuss it again and consider doing the same in SFML.

Besides of that, and I hope it's okay to write that in this thread (don't want to create X threads for connected topics), I'd like to ask if all SFML-related CMake options could be prefixed with "SFML_". I recently ran into the problem where multiple sub-projects used the same CMake cache variables. This can be easily circumvented by prefixes.

Sounds like a good idea.

[Laurent]

Besides of that, and I hope it's okay to write that in this thread (don't want to create X threads for connected topics), I'd like to ask if all SFML-related CMake options could be prefixed with "SFML_". I recently ran into the problem where multiple sub-projects used the same CMake cache variables. This can be easily circumvented by prefixes.

Done.

[Tank]

Thanks.