Hi laurent!
This time I made the patches against sfml2 trunk so I don't bring in patches by accident that are actually already applied
These patches address SFML and CSFML -- python uses a completely different system and I haven't had a look at the other languages
First of all, SFML2 does not build for me, not sure if you already know it. The error message is at
http://random.christoph-egger.org/.sfml2-ftbfshttp://random.christoph-egger.org/.sfml-2/relativ-ln.patch changes the symlinks from libsfml-*.so to libsfml-*.so.* to relative ones. That's the only problem I have currently to use you're DESTDIR implementation unchanged, would be great if it can go in!
http://random.christoph-egger.org/.sfml-2/usr-local.patch might be a bit more controversial. The LSB (LinuxStandardBase) subsystem FHS (Filesystem layout) clearly defines that /usr/{bin,include,share,lib} is only to be used by the package management solutions. Your makefiles installing into /usr/{lib,include} are illegal according to the LSB and can cause real troubles with package managers which all assume they are the only ones to write to prefix /usr.
Changing that to /usr/local would make SFML LSB compliant and package managers won't overwrite a hand-installed libsfml with a system one. As /usr/local comes before /usr on all but more-than-5-years-old RHEL users will get handinstalled Versions of SFML by default when linking their application and a systme installed one is available as well.
Thanks
Christoph