SFML2 library filename

[Tank]

Hi guys, hi Laurent,

like already discussed a little in another thread, I'm personally very confused by the new library filename for SFML2 since you switched over to CMake.

On Linux, every library has a .so name, which basically looks like "lib<name>.so.<version>". The active library is then symlinked to "lib<name>.so". On that platform, another library name is therefore not needed and would lead to inconsistencies.

Libraries that are separately released (e.g. Apache 1.6 and Apache 2.0 in the past) are often also released separately in most Linux' distributions. I think this is an unnecessary confusion. For example, when you do a search with Debian à la "apt-cache search libsfml", there'll popup several versions. Not a bad thing at a first glance, but as a result mechanism that work with .so names won't work anymore -- but besides that potential interested people will just not know why there're two versions and which to prefer (why is there still a 1.6? More stable? 2.0 discontinued?)

Speaking of Windows, I can understand your choice a bit better since there's no version naming for libraries (it's just "sfml-system.dll"). However, this has also been the case for all SFML version up to 1.6. The biggest problem here is of course distribution: When one library version isn't compatible with a previous one, the application/game has to include the library with the release.

However, at the time when packing a release, nobody knows when a library will get outdated by a newer, incompatible version. Therefore this problem will *always* exist (as long the MS guys don't choose to add versioning, too).

As a logical consequence, you had to name all your releases like "sfml-system-1.6.dll" to avoid version clashes. I know, this is not the common case on Windows, but isn't it an option? I.e. .so naming on Linux (Mac OSX does it the same way, right?) and pseudo naming on Windows.

[Laurent]

Thanks for opening this discussion, this naming issue has bothered me for a long time

My main concern is about inconsistencies in linker options: -lsfml-1.6-xxx on Windows, -lsfml-xxx on Linux.

And how do you link to another version of the library (one which is not symlinked to libsfml-xxx.so) on Linux? Without changing the symlink, of course. Does "-lsfml-xxx.so.1.6" work? Because if you can't do that, basically you can't use two different versions of a library at the same time, and thus I don't see the benefit of .so names.

[Tank]

Yep, you can link to absolute files (even paths are allowed). Otherwise there're some tools that change the active libraries shortly. But I think changing the active SFML version in the system isn't a task that you do every half an hour.

Concerning the linker options, you're right. Not only that you have to take care of it, but also every SFML user who wants to develop for multiple platforms. So basically we only have two solutions available:
1. Keep everything as before ([lib]sfml-SUBSYSTEM.(dll|.so)).
2. Keep everything as it is.

My personal opinion is to stick with solution 1. It's rather common.

[Laurent]

In my opinion:
- solution 1 is "cute" but messy
- solution 2 is awful, but technically it seems to be the right thing to do to avoid conflicts

So... solution 1? :lol:

[panithadrum]

Yeah, solution 1 is ok. The user itself should know what library version is using.

[Laurent]

It's not about knowing which version one is using, but rather about mixing multiple versions on the same system. And because on Windows there's no proper versioning / standard install rules, you can quickly end up with two different sfml-xxx.dll accessible from the PATH and conflicting with each other.

And no, usually people don't know what they do

[Tank]

Hehe, that's right.

As a reminder, you could probably write that down somewhere at the tutorials page, i.e. make clear where problems can arise and how they can be avoided. It could be recommended that there're cases where the default naming can cause problems (especially on Windows systems), but that the user has always the option to avoid them by either:

- include the library in their releases,
- build statically or
- rename the libraries themselves.

I think this is very important for final releases, especially for those that have paying customers that don't want to get annoyed. Hopefully the most who sell are clever enough to circumvent this whole thing. Anyways, there doesn't seem to be a solution that solves it all.

One other thing, to bring this dicussion again into the other direction: If you say: "Well, there's the branch 1.x and the branch 2.x, and the first one is still being used (last stable version).", then you've got probably a *good reason* to rename the files to ensure both API versions, which are incompatible with each other, are still available to developers.

In this case it also makes perfect sense to provide separated packages for Linux distributions, for example. In my opinion SFML 1.x will definitely be superseded, so I don't see a real reason for this, but opinions may differ.

[Laurent]

In my opinion SFML 1.x will definitely be superseded, so I don't see a real reason for this, but opinions may differ

It will, but SFML 1.x DLLs won't disappear instantly, they will still be there on users' systems. They will still be used by old apps, and maybe for a long time if those apps are not upgraded to use SFML 2.
And because there's no version management on Windows, an old DLL, even if it's not used anymore, can stay forever

[Tank]

Then those developers better link statically NOW. (or even always?)

[Laurent]

Static link is not a universal solution, most users will stick to dynamic link. For example, if they want to benefit from bug fixes (new minor versions) without recompiling their applications.

[Laurent]

Here is another idea:
- development files (.lib, .a) are named sfml-xxx, which is more consistent with headers which are still <SFML/Xxx.hpp> and not <SFML2/Xxx.hpp>
- .so on Linux follow the standard naming rules: libsfml-xxx.so.2.0.0 with symlinks to libsfml-xxx.so
- .dll on Windows are the only ones where the major version number must appear in the filename: sfml2-xxx, sfml-xxx-2, or whatever
- no idea about Mac OS X, but either the Linux or the Windows naming convention

I think it's more consistent, and developers are not bothered with the version number.

[gsaurus]

I use dynamic linking because I have several dll projects working together on a bigger app (sometimes working as plug-ins) and they all use SFML.

I don't really bother with the naming since I only use sfml2.
That solution seems ok, I think we can't get any better.

[Tank]

Wasn't that idea already proposed? The problem with it is that makefiles (or any other setups) have to be explicitely adjusted to support both platforms (Linux-like environment -lsfml, on Windows -lsfml2).

The question is what compromise is the lesser of the two evils.

[Laurent]

Wasn't that idea already proposed? The problem with it is that makefiles (or any other setups) have to be explicitely adjusted to support both platforms (Linux-like environment -lsfml, on Windows -lsfml2).

No, my idea is to keep the import libraries without the version number and put it only in the DLLs. So for makefiles, it will always be -lsfml-xxx.

It's more consistent because developers always deal with sfml-xxx names, and users with sfml2-xxx (or sfml-xxx-2, or sfml-xxx.so.2, ...).

[Tank]

Alright, then I understood you wrong. That sounds good.