Handling of code-copies from needed 3rd party libraries in s

[christoph]

Hi Laurent!

A long time ago I think we talked about not shipping libraries like glew zlib or libpng in sfml where you argued you want these for the users to ease building. While I'd argue that at least zlib, libpng, libjpeg and maybe the glew stuff is easily available for Linuxers I accept your choice.

However the current status requires a rather large patch for me that needs updating for new SFML releases and others might also prefer using libraries from their system (e.g. because some bug is fixed there?) I'd propose the following:

• In the SFML code use the paths that would be used on a normal Unix/Linux system like #include <GL/glew.h>
• Place the needed libraries somewhere in the top-level directory, arranging the includes and stuff in the same way they're found on Unixes and referenced from Code
• Use -I so the build works with these shipped copies

This would mean all that is needed to not use the shipped copies is a rm -rf used-libraries/*

Optionally the Makefiles could get a option to disable (selectively?) some of the copies as needed.

Hopefully this won't cause much disruption in SFML so if you think a implementation like that will have a chance getting into SFML I'd start creating the patches.

Regards

Christoph

[Laurent]

A long time ago I think we talked about not shipping libraries like glew zlib or libpng in sfml where you argued you want these for the users to ease building

Absolutely

While I'd argue that at least zlib, libpng, libjpeg and maybe the glew stuff is easily available for Linuxers I accept your choice

Well, if we were talking about Linux only I wouldn't even argue, I would remove all the external libraries right now. But unfortunately we're talking about Windows as well.

I'd propose the following:


    * In the SFML code use the paths that would be used on a normal Unix/Linux system like #include <GL/glew.h>
    * Place the needed libraries somewhere in the top-level directory, arranging the includes and stuff in the same way they're found on Unixes and referenced from Code
    * Use -I so the build works with these shipped copies

This solution cannot work, for at least two reasons:
1. It could work if I were linking against those libraries, but what I'm doing in SFML is directly including their source code. So I have to handle their source files as well, not only their headers. One workaround could be to compile them all as static libraries.
2. If I use standard paths for including them, how will I avoid conflicts with already installed versions?

[christoph]

Hm it should AFAIK not matter if e.g. zlib is src/SFML/zlib/* or extern/zlib/* for building the source in. Would need some handling in the makefile (e.g. switch between -lz and the *.o inclusion but should be doable.

For the header conflicts: stuff passed with -I takes priority over system ones

[Laurent]

For the header conflicts: stuff passed with -I takes priority over system ones

For every compiler on every OS? We should first check this before doing any modification.