3 ms·

> 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 pack

by boris 4y ago

> 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/filelist https://packages.debian.org/stable/amd64/libsdl2-dev/filelis...

jcelerier 4y ago
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
- deadbeeves 4y ago
  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.
mort96 4y ago
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).

by boris 4y ago

jcelerier 4y ago

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

deadbeeves 4y ago
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.

mort96 4y ago

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).