Building SFML with some features disabled?

[bananaboy]

Hi,

I've been searching around and I couldn't find anything. Is there any way to build SFML with FLAC and the audio encoders disabled? I don't want nor need them, and I don't want to have to distribute them with my game (especially on Linux - it's one less dependency to have to worry about). I couldn't see any CMake variables or #defines to turn them off though.

Thanks,
Sam

[Hiura]

SFML was indeed not designed to "turn off" some parts of its implementation. But you could fork it and remove manually those parts -- unless a significant number of people ask for that, then it might be done upstream but I wouldn't count on that. 

[binary1248]

I don't see why this can't become a "feature" at some point. Certain implementations can become more problematic than we anticipated (look at Windows joystick stories) and instead of sending the users into the source, they should be able to temporarily disable stuff via CMake as a temporary (or permanent) workaround, or simply as a way to customize the SFML they statically link into their executable. Many other libraries already offer this option.

[Hiura]

@binary1248: not sure whether your comment was addressed primarily to me or not, but for the record I do agree with you. What I meant was that we usually do things because there's a significant demand for it (well, you already know that, don't you. ;-)).

[Laurent]

Linux is usually the system where dependencies are the easiest to manage. You don't have to distribute anything, users just have to "apt install libflac" or equivalent (which will most likely already been done, since flac is such a common dependency for anything that deals with audio).

Personally I'm not against making things optional, but they have to be worth it. And don't forget about the drawbacks: it introduces clutter at configuration time (I'm currently working with a library with tons of CMake options and I'm still trying to figure out which ones I should enable or disable), and most of all, all the SFML libraries built with custom options will generally be incompatible with each others, making the distribution process even harder.

Regarding audio back-ends, since the current system is quite modular, maybe we could think of runtime solutions rather than configuration options -- something like plugins.

[bananaboy]

Ok thanks. I'll probably fork it and do it myself then. I'll issue some pull requests and you can take the changes if you like!

[binary1248]

I also work with libraries where there are seemingly endless options to enable/disable stuff. Almost every source tarball you get on Linux lets you ./configure some stuff in or out. Sure, mixing options will make the library you build incompatible with libraries that others build if the options don't match, but I really don't see why that is our problem. If someone builds a custom version of the library, then we simply have to assume that they know what they are doing. We really shouldn't try to protect users from their own stupidity to the disadvantage of the users who actually know how to make use of such a feature. If they don't understand an option, either read the documentation, ask on the forum or just don't touch it. I don't have any problem following this procedure, and neither should any serious developer.

[eXpl0it3r]

Wouldn't such options quickly add tons and tons of #ifdef into all sorts of places in the code?
Plus we'd have to manually keep track of all the possible dependencies a feature might have.
Unless we refactor the whole code base and extract dependency code even more...

While a good idea I'm not sure if the additional maintenance is worth the effort. Then again, maybe there are some options that really require a small amount of changes.

[bananaboy]

I just issued two pull requests for this (I also added a flag to disable networking).