Comment by boris | Hacker News Reader

Comment by boris | Hacker News Reader

> Mistake 1: Not using sdl2-config

> Mistake 2: Including SDL2/SDL.h

The overarching mistake here is not using a proper build toolchain (build system and package manager). I especially take issue with this assertion:

> The correct SDL2 include is the following:

> #include "SDL.h"

Including headers with the library prefix (#include <SDL2/SDL.h>) is our only hope to have an inter-operable ecosystem of C/C++ libraries. Let me illustrate this with a concrete example. What the article suggests is having the header search path (i.e., -I option from sdl2-config) pointing to the location of the SDL.h header (say, /usr/include/SDL2). But there are other headers[1]in there. Thankfully, most of them have the SDL_ prefix (by all means an exception rather than the rule, when it comes to C/C++ libraries), but not all. For example, there is the generically-named begin_code.h header.

Imagine now that your project is using another library with the same arrangement which also contains a bunch of generically-named headers and one of them happened to be called begin_code.h. Now which one gets picked up depends on the order of the -I options that are passed to the compiler.

[1] https://packages.debian.org/stable/amd64/libsdl2-dev/filelis...

If you use '#include <SDL2/SDL.h>', your software will refuse to compile under a whole lot of circumstances. It assumes a Linux-style situation where you have one 'include' directory with headers from all libraries in it. A lot of systems won't have that; they will instead have separate include directories for the different libraries, and use pkg-config or an equivalent to provide the -I flags. And these systems will all provide flags which make '#include "SDL.h"' work, while '#include <SDL2/SDL.h>' won't work.

Of course, all of this is moot if you don't intend to use a system-provided SDL. If you bundle your own SDL and take care of that with your build system, you can do whatever you want. But if you intend to use a system-provided SDL, and you intend for your software to be somewhat portable, you must use '#include "SDL.h"'.

Now I will agree that it would've been better if SDL decided to make '#include <SDL2/SDL.h>' the canonical include path. And the fact that SDL pollutes your header search space with generically named header is terrible. SDL is not a very good library, it's a "bad citizen". But that's the world we live in. The only ones who can change it are the people behind SDL (and I certainly hope they do change it with a potential future SDL3).

Yes for the sake of everything holy, the only time it's remotely acceptable to include with "" is for a header file corresponding to a source file. Otherwise always always include with <> and with the complete library prefix if possible, e.g. <SDL2/foo.h>, <libavcodec/codec.h>, etc etc and add as few include paths as you can, anything else is calling for subtle bugs if you're unlucky in how your third-party deps name their things

There's something much worse than including a library header with "", which is a library including its own headers (in the same directory) with <>! That means the user has no choice but to modify the include path.

Reply on news.ycombinator.com