Thank you for your great article about SDL2 mistakes:
One suggestion, it seems sdl2-config will be deprecated with SDL3, with
the replacement being the standard pkg-config:
Deprecate sdl2-config and AM_PATH_SDL2
Perhaps it is better to recommend using pkg-config?
SDL2 ships with "sdl2.pc" and the output is effectively the same:
$ pkg-config --cflags sdl2
$ sdl2-config --cflags
$ sdl2-config --libs
$ pkg-config --libs sdl2
Thanks for the note, Jamie. I'm aware that's likely the case for SDL3, but
nobody knows for sure since the first SDL3 release is years away. As a
rule, I avoid planning around yet-to-be-released software since anything
can change. At least some preparation effort will be wasted, which can be
avoided with a bit of patience. Even after SDL3 is released, it will take
years more to mature and percolate, so it's well beyond my consideration
Besides, sdl2-config deprecation is unfortunate. If the official choices
were either pkg-config or CMake, I would not have taken SDL2 seriously
enough to have written this article. (I also cannot in good conscience
recommend use of either pkg-config or CMake.) You might object, "What if
every library had its own config script? It would be a mess." I agree, but
SDL isn't just a library. It's a whole platform requiring buy-in, and so
it sits in a special place. sdl2-config is analogous to musl-gcc, as musl
isn't just another library.
However, the SDL_main situation is changing in SDL3. The current plan is
to push it out of the build and into the source, so as far as the build is
concerned, SDL3 *is* just a library. Even with Mingw-w64, the build would
only be "cc -mwindows app.c -lSDL3", though this invocation will require
installing SDL3 as a library. Straightforward sdl2-config invocation does
not require installation, making this a small downgrade.
(I expect this new SDL_main situation will be just as confusing, and so
most SDL applications will continue mishandling it. Finally addressing
this confusion ought to be an SDL3 goal.)
Ultimately my build recommendation will probably be:
* SDL2: Use sdl2-config. Trivial, works everywhere.
* SDL3: Install, then link with -lSDL3. Apply -mwindows as needed.
The second is already more complex. If it ends up worse than that, then
the recommendation changes to "use something simpler like SDL2."
On Tue, 10 Jan 2023 at 03:08, Christopher Wellons
> Besides, sdl2-config deprecation is unfortunate. If the official choices> were either pkg-config or CMake, I would not have taken SDL2 seriously> enough to have written this article. (I also cannot in good conscience> recommend use of either pkg-config or CMake.) You might object, "What if> every library had its own config script? It would be a mess." I agree, but> SDL isn't just a library. It's a whole platform requiring buy-in, and so> it sits in a special place. sdl2-config is analogous to musl-gcc, as musl> isn't just another library.
I did wonder why you didn't like the pkg-config method, and you make a
good point. Considering this isn't decided with SDL3 yet, maybe it's
worth making a comment upstream to suggest they have an "sdl3-config"
program as well as the likely "sdl3.pc" file?
Such a comment probably has more weight coming from you (well-known C
blogger) than me (nobody) :P
Going back to the overall post, I tried to apply the SDL-as-platform
coding style to my current project, I think there's actually two ways
to write SDL.
First is "an SDL application" as your article says. This depends
entirely on SDL and instantly runs on obscure weird platforms like
maybe the Vita or PSP or GP2x or Android NDK, but also runs on
computers. Second is "a C application which uses SDL" which probably
only runs easily on computers, but can also be decoupled from SDL.
An example of the second is my current project - a roguelike which I'd
like to use SDL for graphical tiles, but I also want to completely
separate the game logic from the renderer, and possibly slot in
another renderer like ncurses or an alternative graphics engine like
You've made me reflect on pkg-config again, and our discussion here has
had a concrete result. So thanks for bringing this up, Jamie! This weekend
I wrote a new pkg-config from scratch with first-class Windows support,
suitable for inclusion in w64devkit:
If PKG_CONFIG_PATH points at the unzipped SDL2, or if SDL2 is copied into
the w64devkit sysroot, it works perfectly with its sdl2.pc. I've also
tested smaller libraries, and they also work perfectly. There's more
testing to do, but the next w64devkit *will* include a well-functioning,
native pkg-config. I'm now comfortable recommending its use with SDL2, and
for the same reason I'm fine with the SDL3 plan. I'll publish an article
on this soon, and then update the recommendations in my SDL2 article.
My original objection was that pkg-config's ultimate job is simple: copy
some text from .pc files to standard output. However, the implementation
is overwrought, requires autotools, and yet does not even work properly on
Windows (where I care about smooth SDL operation). That's not a great
trade-off. However, as I discovered writing u-config, lots libraries
define .pc files, and it's a rich database of information, even simply as
a human reference. It's worth tapping into that, and pkg-config's effect
in causing this distributed database to emerge is good.