Thank you for your great article about SDL2 mistakes:

 https://nullprogram.com/blog/2023/01/08/

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
 https://github.com/libsdl-org/SDL/pull/6467

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
 -D_REENTRANT -I/usr/include/SDL2

 $ sdl2-config --cflags
 -I/usr/include/SDL2 -D_REENTRANT

 $ sdl2-config --libs
 -lSDL2

 $ pkg-config --libs sdl2
 -lSDL2

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

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
<wellons@nullprogram.com> wrote:
> 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
raylib/SFML/Allegro/etc.

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:

https://github.com/skeeto/u-config

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.