| cire (1845) | |||
It's the source code section. Not binaries and libraries supplied section. One needs to compile the SFML source code to use the SFML libraries. The libraries are not compatible between compiler versions, between debug and release builds, or between compilers and certainly not between platforms. That's a lot of cruft you would have to include to keep people from having to visit the place they should already be visiting if they want to use SFML. It would make more sense to me just put it on the SFML wiki where people who are interested in it will be looking for it. As an aside, SFML 1.6 is outdated, unmaintained and much buggier than the current version. If only Laurent would make that more obvious on the front page of the SFML site, it would quell a lot of confusion from new users.
A non-trivial project should have a home in the form of a code repository or website somewhere. Linking to it seems more appropriate to me than duplicating it. | |||
|
|
|||
| Luc Lieber (907) | ||
|
...my point is that depending on third parties to a) host project dependencies, and b) maintain project dependencies makes for an extraordinarily fragile system if stability and ease of use are design considerations. What happens if the SFML website goes down tomorrow or the author decides to break some backward compatibility? I'm not saying that it will happen, but if it does, now all of your source code is pretty much useless. Ever try to find a certain version of a library that you need for extending an in-house code-base only to find that the project is now abandonware with a broken link for a website? If only the previous maintainer had kept a copy of it instead of just a link. I guess that's how the open source world operates, but IMHO it's too sloppy for me to adopt.
Yes, if only XXX would YYY, but we are effectively at their mercy. By the way, this may sound like an attack, but don't take it like that. | ||
|
Last edited on
|
||