Improve CMake for IDE Projects (Visual Studio)

[playmer]

Some relatively small changes to the CMake to make generated IDE Projects more usable. I primarily use and hack on SDL from Visual Studio, and often using vcxprojs created by the "Visual Studio *" CMake generators. As it is, VS doesn't know about the headers because they're not added as "sources", so things that rely on the vcxproj info can't display them. It makes it difficult to jump around and look for headers.

Additionally there's a change to make the Solution Explorer have more detail than just "source" and "header" filters, instead setting up filters that match the file structure.

Description

For adding the headers, two small changes were needed. In the glob where we look for sources, we needed to add globs for headers, which gets us the internal headers. For the public headers, we were already tracking these in a variable, and on Apple we were already doing what needed to be done, I just moved that small piece outside of the Apple only check. It might be that there's a better place for it, but it needs to be after we've appended everything to it.

The "filters" problem was more difficult, exclusively due to how android builds SDL and how the JNI sources aren't within it. Ideally we'd essentially just call source_group(TREE ${${PROJECT_SOURCE_DIR} ...) inside sdl_glob_sources and sdl_sources, but this fails due to those JNI sources being in a sibling directory to the PROJECT_SOURCE_DIR and source_group not having any way to ignore pathing errors. I ended up just writing a function to filter out paths that weren't within our project dir, and called it a day. It's slightly more complex than it needs to be since we're using CMake 3.16, but it should be okay.

Anyway, thanks for considering this change :)

[madebr]

Looks good!
I think you missed some Windows sources/headers.

[madebr]

There's some more sdl_glob_sources under if(WINDOWS).

[playmer]

Sorry for the delay. wasn't able to tinker on this for most of the day. Looking at it more closely, there's actually a ton more that I've missed. Now I wonder if I should change approach and augment sdl_glob_sources to get the directories of the files passed in and add additional *.h globs in. What do you think? It'd certainly be less work to maintain it, (For however much work it really is to add a few extra lines of CMake to account for headers is.) Though it might be better for it to accept directories rather than files...I dunno!

[madebr]

I'd rather not make the globs too smart.
We're already not following cmake best practices by not explicitly listing the sources.

[playmer]

Yes, I do much prefer being explicit, but I know that doesn't work for everyone. I'll do a thorough pass tomorrow and try not to miss any.

As a tangential question, is there a reason the GLOBs aren't using CONFIGURE_DEPENDS?

[madebr]

I didn't know about that option.
If performance does not suffer, it makes sense to use it.

[playmer]

Oh sorry, I got caught up working on my SDL_MenuBar prototype, my plan was to do CONFIGURE_DEPENDS as a separate change so I didn't end up prioritizing it. I can work on that tonight!

[madebr]

A separate PR is OK as well. I was just checking in.

[playmer]

Did some testing locally, I'm not noticing anything that I would be able to consistently nail down without just running builds over and over again. I pushed it up to CI and while it wasn't faster than the previous run on the branch, it was faster than a different run on the same commit.

Previous Commit Run 1: https://github.com/playmer/SDL-1/actions/runs/16858095731
Previous Commit Run 2: https://github.com/playmer/SDL-1/actions/runs/16857983229
CONFIGURE_DEPENDS Commit: https://github.com/playmer/SDL-1/actions/runs/16953366708

The flag should mostly affect incremental builds, as CMake needs to insert globs to run before building your code. I did a quick run of a rebuild by inserting blank lines in SDL.h and again found nothing notable:

(Omitted the actual cmake/build output, but the full logs are here: https://gist.github.com/playmer/7d2c0bc75d694e582c08601f23f5b72b)

With Changes:

playmer@Timestar:~/SDL_test/SDL_with_change$ time cmake -B build .
real    0m48.004s
user    0m6.040s
sys     0m3.943s
playmer@Timestar:~/SDL_test/SDL_with_change$ time cmake --build build -j8
real    0m7.513s
user    0m44.668s
sys     0m6.852s
playmer@Timestar:~/SDL_test/SDL_with_change$ nano include/SDL3/SDL.h
playmer@Timestar:~/SDL_test/SDL_with_change$ time cmake --build build -j8
real    0m7.594s
user    0m44.934s
sys     0m7.024s

Without changes:

playmer@Timestar:~/SDL_test/SDL$ time cmake -B build .
real    0m46.969s
user    0m6.005s
sys     0m3.781s
playmer@Timestar:~/SDL_test/SDL$ time cmake --build build -j8
real    0m11.172s
user    0m45.076s
sys     0m7.158s
playmer@Timestar:~/SDL_test/SDL$ nano include/SDL3/SDL.h
playmer@Timestar:~/SDL_test/SDL$ time cmake --build build -j8
real    0m7.622s
user    0m44.630s
sys     0m7.069s

[playmer]

I can push the change to this branch or not, don't want to make the decision for you! Just let me know what you'd prefer!

[madebr]

Let's do it in a separate PR and let this one focus on making IDE's pretty again.

[slouken]

Merged, thanks!

[eszlari]

Just a note: This PR will improve the development experience not only for VS but also for other IDEs that support CMake, e.g. Qt Creator.

[playmer]

I knew that source_group and the header stuff was IDE agnostic, hence why I led with it, but I just wasn't aware of what other tools/generators used it other than VS. Good to hear QtCreator is one of them :)