Hi Christoph
I'm not sure whether this patch is really good or not. SFML libraries are not linked against each other on purpose: I think it's good that users explicitely see what modules they are using.
OK I suspected that argument. If you want to keep it that way it's your decision, I'll have to patch it for my part but that's not much of a problem.
Personally I prefer if I can guess the libraries I need to link to from my sources correctly witout any second thought
Plus, I think they will be in trouble if both SFML and them link against the same library ("multiple definitions" errors -- or is the linker smart enough?). This would be even worse for static libraries.
For dynamic libraries the linker is able to cope with that. There's just one potential cause of problem: If I use a sfml-graphics linked against some version of sfml-system and link against
another version of sfml-system as the symbols are not versioned and the linker now sees 2 different dynamic libraries. However I doubt this has any relevants in reality.
Static libraries are, of course, another case and should probably be solved, if at all, with pkg-config.
However I agree with you on this point:
The libraries become dlopen() able
So, what do you think?
If you decide to leave everything as is, please consider adding GL and X11 to libsfml-graphics linker at least they're missing as well (sfml-window is linked against GL but that doesn't propagate to -graphics, IIRC you will need to ass -lGL even if you have -lsfml-graphics -lsfml-window)
