SFML community forums
General => General discussions => Topic started by: Ceylo on January 04, 2018, 10:16:56 pm
-
Hello,
I’m wondering why each SFML module is represented by a distinct dynamic library file? Rather than a single SFML.dll.
I understand the semantic separation by related features, but this only requires separation by modules in documentation and in the API. When doing a new release, all modules are shipped together with the newer version, there is no independent versionning. Also all the modules account for less than 2.5MB so I see no need to sometimes ship only part of SFML for lighter distribution. This makes linking against SFML uselessly "complicated" (it’s quite simple already actually but could be simpler), and makes the project structure for SFML developers also more complicated than necessary.
So I’m wondering... why the split in several library files ?
-
Because not everyone needs all the modules all the time. 80% of the SFML projects probably never use the network module.
What's the real downside of having it split "physically"? Is linking or shipping one library really that that much simpler?
-
Because not everyone needs all the modules all the time. 80% of the SFML projects probably never use the network module.
So ? It doesn’t matter if you don’t use everything and have everything for the same price. What’s the advantage in having minimalist binaries when the whole package is 2.5MB?
What's the real downside of having it split "physically"? Is linking or shipping one library really that that much simpler?
More complicated than needed. Why care about which module you link against? Why should you need to care about the link order? Why should your app need to have 5 or 6 dynamic library files installed or shipped (for systems that favor dynamic libs) when it actually depends on a single API?
-
Don't forget that a SFML module is not just a shared library, it also brings with it a bunch of system dependencies. Maybe some people don't want to install all the audio libs if they don't use audio (there's even a request to add options to disable codecs within the audio library, to reduce the amount of dependencies to what's strictly needed). Or maybe people simply can't compile the graphics module because they have no display (and thus no X & GL libs), but they don't care since they only use audio and network.
-
Don't forget that a SFML module is not just a shared library, it also brings with it a bunch of system dependencies. Maybe some people don't want to install all the audio libs if they don't use audio (there's even a request to add options to disable codecs within the audio library, to reduce the amount of dependencies to what's strictly needed). Or maybe people simply can't compile the graphics module because they have no display (and thus no X & GL libs), but they don't care since they only use audio and network.
Ok indeed. Do you know the percentage of users that want to use only some parts of SFML? Especially how many don’t want audio or graphics/window, since this is where there are most dependencies?
-
I have no idea, probably not that much. But definitely not zero.
-
To some extend it certainly also comes down to personal preference. I mean, why a shared library at all, why not header-only? ;)
Fact is, that only with a modular library you can pick and choose the feature set and connected dependencies you need.
C++ library linking situation simply isn't that great as other languages dependency management. This affects us as much as any other library out there. People having trouble linking one or multiple libraries isn't really a problem SFML should try to "solve", because it's not that this is a complex thing, but it's just something you have to learn when working with C++, yet a large percentage of SFML user have little to none C++/programming experience. We shouldn't base our decisions around that group of people.
Also not forget, with a monolithic SFML library, you'll also have to always ship the OpenAL.dll (on Windows) regardless whether you use SFML's audio part or not. And as Laurent mentioned, you wouldn't be able to run SFML on a headless setup.
-
I think the argument to split SFML in several DLLs to lower the global project size if a module isn't needed is not very realistic, since if you really care about size, you just statically link.
-
Just the ability to build as separate dll's is an indication of good design. There are clear dependencies between modules and you do not have to build 'everything' just to get something working.
-
I'm usually on the side of simplicity but not here.
System is common stuff and it can't be duplicated if other libs are split, Audio makes sense to be split out to not force people to bring in OpenAL if they don't want audio or the rest if they do (i.e. I'd use SFML audio if I was using Irrlicht for 3D), Network is hardly stellar (I never used it personally..) and Window makes sense to be split out (for pure GL and input).
Maybe a Graphics and Graphics-and-Audio dll targets could be made (I'm kinda biased against Network) but if you really care about this then you just link statically.
-
Don't forget that SFML is not licensed under LGPL, so it has no licensing effect on your project no matter how you use it. You're not forced to use the shared library version. If you want something monolithic, you can just build or use the static version of SFML, either in your own library or right with the executable.
-
Splitting it has benefits which have already been mentioned in this thread. For me personally, it's never been the source of difficulty or inconvenience, and I didn't exactly have a lot of experience in programming when I first started using SFML.
-
Sometimes, you might just want the audio section so needing to link the whole Graphics package with its dependencies seems a bit like overkill.
-
If you really want to have a single lib, build SFML static, and link all the libs together into a single SFML.lib ( || SFML.a)
You do this **once**, after that you have exactly what you want.
-
Just the ability to build as separate dll's is an indication of good design. There are clear dependencies between modules and you do not have to build 'everything' just to get something working.
This is indeed a good argument because it shows that encapsualtion is done right with SFML.