3 ms·

GNUmakefile: LDLIBS += $(shell pkg-config --libs sdl2) CFLAGS += $(shell pkg-config --cflags sdl2) prog: prog.o Then you just run `make` or `

GNUmakefile: LDLIBS += $(shell pkg-config --libs sdl2) CFLAGS += $(shell pkg-config --cflags sdl2) prog: prog.o Then you just run `make` or `gmake` (the developer should be aware of what his platform of choice prefers to call gnu make) and prog.c gets compiled to prog using the appropriate flags. I missed out some important details like setting the standard revision but I wanted to keep this short. This will work with gnu make, gcc and clang on linux, mac, any BSD, and windows (under wsl or msys or cygwin). Cross compilation is possible too. Personally I would use redo as the build system but this is shorter in make for such a simple project. More complex projects can be made to work with this basic pattern. When using autotools, cmake or meson you also have plenty of good options although I'm not entirely familiar with them as I don't use autotools, cmake or meson. Obviously this won't work if your machine is broken or if you don't have SDL2 installed in the correct place, but these are concerns for the package manager. The documentation simply needs to instruct you to install SDL2 (with development headers and the pkg-config definition). If you need a more advanced use-case such as you're trying to vendor the dependencies, you need to deal with PKG_CONFIG_PATH but I should stress that vendoring is NOT a normal use-case in the open-source-project-relying-on-sdl2 world.

sanxiyn 5y ago
The main deficit here is package manager. People are not writing yet another cross-platform package managers for no reason. Providing a consistent cross-platform experience is a value add. With "use system package manager", you'd need something like the following at least: On Windows/MSYS2, run pacman -S mingw-w64-SDL2. On macOS/Homebrew, run brew install sdl2. On Linux/DEB, run apt install libsdl2-dev. On Linux/RPM, run dnf install SDL2-devel. Which is no fun, not to speak of problems when versions in system package managers are different.
- Arch-TK 5y ago
  Using the system package manager means that your software can actually in the future be packaged for a distribution. This is a major win in the sense that if your software ever achieves any level of popularity, it is more likely to actually get packaged and as a result, your end users are more likely to actually be able to easily make use of it. Distro package managers are a far superior solution than having 5 different language package managers you have to keep in sync and then having to compile your own software.

sanxiyn 5y ago

The main deficit here is package manager. People are not writing yet another cross-platform package managers for no reason. Providing a consistent cross-platform experience is a value add. With "use system package manager", you'd need something like the following at least: On Windows/MSYS2, run pacman -S mingw-w64-SDL2. On macOS/Homebrew, run brew install sdl2. On Linux/DEB, run apt install libsdl2-dev. On Linux/RPM, run dnf install SDL2-devel. Which is no fun, not to speak of problems when versions in system package managers are different.

Arch-TK 5y ago
Using the system package manager means that your software can actually in the future be packaged for a distribution. This is a major win in the sense that if your software ever achieves any level of popularity, it is more likely to actually get packaged and as a result, your end users are more likely to actually be able to easily make use of it. Distro package managers are a far superior solution than having 5 different language package managers you have to keep in sync and then having to compile your own software.