Review build systems

[slouken]

Review the set of build systems. It would be nice to reduce the number of build scripts and leafy build system files. If we standardize on CMake, what is covered that we can remove?

@libsdl-org/a-team

[slouken]

For now let's remove autotools and keep CMake and Visual Studio and Xcode projects.

@sezero, would you like to do the honors?

Can you prefix each commit with "autotools: " in case we need to roll them back?

[sezero]

Can you prefix each commit with "autotools: " in case we need to roll them back?

It will be a single commit unless I'm missing something?

[sezero]

And, what will you do about creating a release tarball, i.e. make dist relies on autotools build system?

[sezero]

Can you prefix each commit with "autotools: " in case we need to roll them back?

It will be a single commit unless I'm missing something?

And, what will you do about creating a release tarball, i.e. make dist relies on autotools build system?

Anyways, I created #6605 as a first shot at it

[slouken]

And, what will you do about creating a release tarball, i.e. make dist relies on autotools build system?

@madebr to the rescue? :)
How do CMake projects typically create the package archive?

[madebr]

CMake has CPack to generate binary and source releases.

The default source generator is imho a bit lousy because it simply copies everything excluding files matching the ignore list.
But it is usable, assuming you run it in a clean source tree (git clean).
Alternatively, you can have fine grained control using (non-CPack) components.

This blog gives a short tutorial how it can be done.

For make distcheck, I don't think CMake has something equivalent.
We'ld need to "roll our own" for that one.

[slouken]

The distribution archives are always made from a clean checkout, so CPack may work fine in this case.

Thanks!

[slouken]

Actually, with autotools complexity gone, I think we can just remove the .git folder and zip up the archive as-is.

[madebr]

Actually, you can create it with git directly using this one-liner:

git archive release-2.26.0 --prefix SDL2-2.26.0/ -o SDL2-2.26.0.tar.gz

The last release added some complexity with VERSION, but that dependency can be removed.

[slouken]

Sweet! :)

[slouken]

No worries, I'll take care of it.

[sezero]

SDL_revision.h is another problem.

[ericwa]

For now let's remove autotools and keep CMake and Visual Studio and Xcode projects.

FWIW, I've had good luck with generating project files for both of these IDE's from SDL's CMake project. (e.g. with cmake .. -G Xcode or cmake .. -G "Visual Studio 17 2022".)

In my case, I just wanted the IDE projects for working on / debugging SDL, and the CMake-generated ones worked fine for that.

Depending on what people are using the Visual Studio and Xcode projects for - maybe there are some use cases where it's better to have a handcrafted .sln / .xcodeproj - dropping them and using CMake to generate them locally might be a possibility.

[slouken]

Good to know.

A generated Visual Studio solution might work. @madebr, do we have the ability to replicate the existing Visual Studio solutions for Win32, UWP, and GDK, using CMake?

[slouken]

@madebr, I'm about to nuke autotools in SDL3, are you ready for the swarm of people trying to use CMake on random old build environments? :D

[madebr]

So far, I've only tested the default MSVC Standard desktop configurations.
"Exotic configurations" such as targeting UWP/GDK are a bit unknown to me (and untested by me).

About support of unix-like systems, I think we're in a good position.
As the cmake script does not use system utilities such as e.g. grep, I'm not that concerned about older platforms.