Update SDL 2.0.12

I’ve started a branch to update SDL from 2.0.10 to 2.0.12 as hdiapi gamepad support in 2.0.10 is awful.

It doesn’t even compile on windows yet. Any help is welcome.


I could have a look but not after I wrap up a few other things in the dev branch I am currently working on. But I will most probably start a new instead of fixing on top of yours.

Shall I abandon this one then?

If you still want to try to get it work then no harm to keep the PR there first. I actually haven’t looked at it though. Who knows it is just a simple mistake.

I suspect the problem is in cmake file.

If you going to do it yourself in next couple weeks I can wait. Otherwise I’ll try to make it work.

We are using heavily modified CMake build scripts. For sure you cannot just simply replace that with the original but upgraded scripts from SDL and expect it to work.

I didn’t replace it, I kept the one that was in Urho. Although it is hard to track what is different there since it is very different from original SDL 2.0.10 cmake.

My question is if you have a SDL upgrade timeline on mind or it may happen “some time in future”.

I know exactly what you are saying. Believe me. Over the years, I have come up with my own way to keep track of the local as well as the upstream changes and able to “systematically” merge the changes together. However, it is still rather a convoluted process using git and vi to resolve any conflicts. Not easy for me to elaborate here, although I have written the gist of it in my personal github account. It was a mental notes for myself and I don’t expect anyone else to read and understand from it.

I don’t have a specific timeline for it. Actually I have another bigger fish to fry in my current dev branch.

1 Like

Ok, then I’ll try to make it work myself.

Btw do you know how to switch joystick support from hid to xinput or xinput? This would also work for me fine.

7 posts were split to a new topic: Return of the nag

I am also not the expert of SDL. I just know one thing or two on how to get the upstream changes merge into the Urho3D from earlier experience through trial and error. Practice makes perfect, they say. However, in actual fact, for each upgrade I have to spend a lot of time and energy to reconcile the conflict, but I am not as fit anymore. I just have a systematical way to identify the changes (thanks to Git), but the hard labor is in conflict resolution. In other words, whether you and I have the systematic way for performing the upgrade or not, we both will face the same daunting task. And, no, I don’t know the answer to your last question.

1 Like

What happened to 2.0.11? They just jumped from 2.0.10 to 2.0.12?

Looks like it… I don’t know why.

I also wonder if they going to produce 2.0.13 in the middle of the merge… That would be unfortunate :slight_smile:

May I ask you where SDL_EXPORTS is defined? I can’t find it in cmake files…

It is used there but I can’t find where it is defined…

// Urho3D: Only export when it is being requested

I think it is basically just a way to make it not exported. Urho3D builds all its sub-libraries as STATIC.

1 Like

Samples reference Urho3D. Urho3D reference SDL. Sample compilation fails because of missing SDL functions like SDL_free.

Any ideas why it would be?

You meant building “Urho3D” lib itself is fine? And only failed in samples?