@weitjong i can not help but observe a repeating history. I believe same exact cause resulted in build system to remain a stagnating pile of legacy hacks. When i wanted to fix it - i inevitably needed your help, but you had other things to do. Now someone wants to update SDL. Likewise you have other things to do. No one has a right to demand these things from you of course. However we are in a situation where a maintainer assumes exclusive control of certain parts of the project and is not interested in mentoring future contributors. This simply drives those contributors away. Attempts to improve something without support of maintainer of those subsystems is doomed to fail. I am quite disappointed that these attempts are driven to the ground just like that. Project is not exactly flourishing and does not quite have that many potential contributors to waste. Make your own conclusions now.
I have also a little criticism regarding modifications in SDL cmake script. When i tried to look into upgrading SDL, this part stood out as extremely complicated, because of tiny one reason: modifications are commented and they say “commented out this and that”, while in reality code from CMakeLists.txt is removed. This creates quite a problem when comparing to upstream cmake script as it is not clear what parts should be omited and what parts were added in upstream between our current version and upstream version, and should be ported to our build script. I would prefer dead code be commented out for the sake of simplifying updates. It may not be a problem to you @weitjong personally, but it artificially raises a bar for new contributors. Actually i would argue same policy should be adopted for modified source code, commenting out original bit and adding a modified section, instead of modifying original code directly, losing ability to see exact modifications versus upstream version at that time.