We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2917 - SDL fork compatibility
Summary: SDL fork compatibility
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: don't know
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-22 06:32 UTC by x414e54
Modified: 2015-03-25 15:16 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description x414e54 2015-03-22 06:32:43 UTC 
I just wanted to draw your attention back over to the UE4 SDL-gui-backend fork before things get too crazy over there.

It has become a complete wild-west and is going to quickly end up causing some issues for the end user trying to override with an updated version of SDL.

Whilst the dynapi will protect the end user from static linking and allow them to load in newer version of functions it is insufficient to protect the user against API changes.

Most of the new functions added in hopefully would just fail gracefully but there could be some issues with additional enums that have been added or current functions which have been changed to work in different ways.

Taking a look at the Events for example they are just integers and not type-safe. This means if a fork adds a new Event and does something such as closes the application and SDL adds a new Event which overlaps the fork. When the user overrides with the newer version of upstream SDL they might receive the new event and the application closes.

Possibly converting the enums to strings or having certain ranges allowed for custom events which will never be used by SDL, might be better. Or forcing forks to always use the SDL_UserEvents.

Also the current SDL_DYNAPI_VERSION is insufficient as it is only meant to be changed by upstream SDL. If for example it is changed to 2 by the fork and then upstream also changes to 2, the fork dynapi could still load the incompatible upstream library.

There really should have been some fork protection clause in the license to prevent end-users being screwed over. Or possibly something from Valve's side which says any games shipped on Steam must be compatible with the upstream SDL just to force developer's hands.
Comment 1 Ryan C. Gordon 2015-03-24 06:24:11 UTC 
(In reply to x414e54 from comment #0)
> I just wanted to draw your attention back over to the UE4 SDL-gui-backend
> fork before things get too crazy over there.

We are already working with Epic to get their changes upstreamed as appropriate. 

If they break ABI in their builds, they need to deal with the consequences of that, though (which might mean that people need to manage a separate fork, etc. Since UE4 source code is readily available, this isn't ideal, but it's not the worst problem ever. In perfect world, they're working with a standard SDL that has features they need, though).

(if they change the SDL_DYNAPI_VERSION, they should change it to something large, like 0xFFFFFFF, or better yet, turn off DynAPI entirely.)

--ryan.
Comment 2 Dmitry 'RCL' Rekman 2015-03-24 15:05:03 UTC 
The long term goal is to upstream changes made in the UE4 fork and/or otherwise make UE4 shippable on stock SDL. For the time being it might be wise to indeed disable the DynAPI.
Comment 3 Ryan C. Gordon 2015-03-25 15:16:48 UTC 
(In reply to Dmitry 'RCL' Rekman from comment #2)
> For the time being it might be wise to indeed disable the DynAPI.

To do this, you should edit SDL/src/dynapi/SDL_dynapi.h and look for this:

#else   /* everyone else. */
#define SDL_DYNAMIC_API 1


Change that to 0 and rebuild everything.

--ryan.