Why does SFML provide multiple header files for some dependencies?

[Symphonym]

I'm in the process of developing a  little engine project of my own and got some questions regarding how to package the code base in order for it to be used by others (such as SFML). My understanding is that you provide the header files for the dependencies, which is platform-independent as there (should) be #ifdef's and similar depending on the platform it is compiled on. Then platform-specific library files (.dll, .framework, .lib and whatnot) are provided which is what the project will link against. On Linux platforms neither headers nor library files are provided since they might vary between distros and it's better to just use the versions that the distro repos provide.

But as I'm going through the SFML extlibs/headers folder I've noticed that platform specific header files are provided for libsndfile and libfreetype, why is that the case? Shouldn't a library that is cross-platform take care of this in a single header file using #ifdefs or similar? I've also noticed that no OpenGL headers are provided, I assume that the lack of them means that the header files are different depending on both graphics drivers and operating system. As otherwise couldn't they just be packaged per-platform like libsndfile (still don't understand why this is the case though)?

Anyone that could help bring me some clarification on this issue? Even though it might not be super specific to SFML itself.

[Jesper Juhl]

I'm wondering why, if you are using SFML, you worry about underlying dependencies like libsndfile at all..?
Isn't the whole point (or at least a large part of it) that you include the SFML headers only and don't worry about the underlying dependencies?

[Symphonym]

I'm wondering why, if you are using SFML, you worry about underlying dependencies like libsndfile at all..?
Isn't the whole point (or at least a large part of it) that you include the SFML headers only and don't worry about the underlying dependencies?

Because I have dependencies other than SFML and I'm wondering how I should include those with the project.

[Jesper Juhl]

Do those "other dependencies" overlap with SFML's dependencies?
If not, then I don't see the problem.
If there is overlap, then I still don't really see the problem, since you include some SFML headers and link dynamically and then also include some header from a dependency and link dynamically. The headers shouldn't conflict if it's the same underlying library and the runtime linker will sort out the dynamic libraries.
Unless you want to use two different versions of a shared dependency I don't see how there would be much of a concern.
Is there a specific problem that you are having?

[Symphonym]

Do those "other dependencies" overlap with SFML's dependencies?
If not, then I don't see the problem.
If there is overlap, then I still don't really see the problem, since you include some SFML headers and link dynamically and then also include some header from a dependency and link dynamically. The headers shouldn't conflict if it's the same underlying library and the runtime linker will sort out the dynamic libraries.
Unless you want to use two different versions of a shared dependency I don't see how there would be much of a concern.
Is there a specific problem that you are having?

I think you've missunderstood my question. I'm not having any problems with SFML or dependencies, I'm just interested in knowing how to go about when packacking external dependencies with your projects so that other users (on different platforms) may use it as well. Which is why things such as platform-specific header files for some the libraries SFML use confuses me since I would expect that a single header file with #ifdefs would be enough. Also the example with OpenGL to which no headers nor library files are included, why is that the case?

[Jesper Juhl]

Why would you distribute header files with your project?
You'd distribute the .DLL, .so or .dylib files for the relevant platform. Header files are a build-time only concern.
As for locating the correct libraries that you distribute. On Windows you'd just stick them in the same directory as the executable and they'll be prefered over OS provided ones. On Linux you'd use the -rpath linker option together with $ORIGIN to form a prefered path to the libraries relative to your executable. On OS X I forget the details, but you can do similar stuff to ship a self contained bundle.

[Laurent]

Dependencies headers need ot be distributed only for people who want to recompile your library, not for the end users (just in case it was not clear).

Some cross-platform libraries handle platform-specific differences in their build system rather than preprocessor tests in their code. For example, they use CMake, autotools, scons or any other meta-build system, to configure their sources and adapt them to the target platform. That's why there can exist several versions of the headers of a given library.

OpenGL headers are shipped with your compiler (on Windows), that's why SFML doesn't provide them.

[Symphonym]

Dependencies headers need ot be distributed only for people who want to recompile your library, not for the end users (just in case it was not clear).

Some cross-platform libraries handle platform-specific differences in their build system rather than preprocessor tests in their code. For example, they use CMake, autotools, scons or any other meta-build system, to configure their sources and adapt them to the target platform. That's why there can exist several versions of the headers of a given library.

OpenGL headers are shipped with your compiler (on Windows), that's why SFML doesn't provide them.

Ah I see. I just took another look at the source of libsndfile and they are indeed using autoconf and a .h.in file which will generate different header files depending on the platform so thanks for clearing that up.

But do libraries mention this at any point, or do you have to dig through the source to find out whether or not you're fine with one version (for all platforms) of the header files?

[Jesper Juhl]

If the library is not utter crap, then it is not something you need to worry about as a user.
You'll just "#include <library.h>" and the library's build system or #ifdef's in the header will have taken care of the platform specific details. And since header files only matter at compile time it's not something that you need to worry about when distributing the final app. If it build then the headers were fine - period.
(Yes OK, I'm simplifying. But that's more or less it in most cases)