Compiling with SDL_NO_COMPAT

SDL Development
#1

Hi!
I was trying to compile SDL without the compatibility layer; I thought
that this could be achieved by defining SDL_NO_COMPAT but I found out
that several sections of sources won’t compile with it. I took my stab
at fixing this and created this patch:
http://dl.dropbox.com/u/24468/nocompat.patch however I’ve only tested
it against the ios build.

I often read that people added this symbol to their sources, would be
nice if they shared their mods.
Anyways is this patch good enough to be included in the sources?

thanks
Vittorio

#2

SDL_NO_COMPAT is, if I understand correctly, a way of ensuring that no v1.2 only functions are being used in your project. In other words you MUST use only v1.3 functions. This, in turn, ensures that the compatibility layer is not used, which is a good thing in some cases as this layer can cause problems (for example on Android).

SDL itself shouldn’t be compiled with SDL_NO_COMPAT, and if your own project is giving compile errors with the flag you need to make sure you’re not using legacy functions. Correct me if I’m wrong here guys [Wink]

#3

I believe that is correct, it should only be defined in your project -
http://wiki.libsdl.org/moin.cgi/CategoryCompat
When including SDL, do something like this:

#ifndef SDL_NO_COMPAT

define SDL_NO_COMPAT 1

#endif
#include <SDL/SDL.h>

Make sure, as wilbefast said, that you get rid of all the SDL 1.2 calls,
like SDL_SetVideoMode, or any other call that is listed in the wiki page I
linked you to.
If you’re not sure what the SDL 1.3 equivalent is to a call you’re making,
just ask on the mailing list/forum, and we’ll be able to help.

Take care,
-AlexOn Wed, Nov 23, 2011 at 7:19 AM, wilbefast wrote:

**
SDL_NO_COMPAT is, if I understand correctly, a way of ensuring that no
v1.2 only functions are being used in your project. In other words you
MUST use only v1.3 functions. This, in turn, ensures that the compatibility
layer is not used, which is a good thing in some cases as this layer can
cause problems (for example on Android).

SDL itself shouldn’t be compiled with SDL_NO_COMPAT, and if your own
project is giving compile errors with the flag you need to make sure you’re
not using legacy functions. Correct me if I’m wrong here guys [image:
Wink]

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#4

It is perfectly fine to use SDL_NO_COMPAT in my project only, what i mean
is that right now the project will fail without the patch i attached.
VittorioOn Wed, Nov 23, 2011 at 3:23 PM, Alex Barry <alex.barry at gmail.com> wrote:

I believe that is correct, it should only be defined in your project -
http://wiki.libsdl.org/moin.cgi/CategoryCompat
When including SDL, do something like this:

#ifndef SDL_NO_COMPAT

define SDL_NO_COMPAT 1

#endif
#include <SDL/SDL.h>

Make sure, as wilbefast said, that you get rid of all the SDL 1.2 calls,
like SDL_SetVideoMode, or any other call that is listed in the wiki page I
linked you to.
If you’re not sure what the SDL 1.3 equivalent is to a call you’re making,
just ask on the mailing list/forum, and we’ll be able to help.

Take care,
-Alex

On Wed, Nov 23, 2011 at 7:19 AM, wilbefast wrote:

**
SDL_NO_COMPAT is, if I understand correctly, a way of ensuring that no
v1.2 only functions are being used in your project. In other words you
MUST use only v1.3 functions. This, in turn, ensures that the compatibility
layer is not used, which is a good thing in some cases as this layer can
cause problems (for example on Android).

SDL itself shouldn’t be compiled with SDL_NO_COMPAT, and if your own
project is giving compile errors with the flag you need to make sure you’re
not using legacy functions. Correct me if I’m wrong here guys [image:
Wink]

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#5

Fwiw, I’m considering just ripping out the compat layer (you can always
just use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

–ryan.On 11/23/2011 10:02 AM, Vittorio Giovara wrote:

It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
mean is that right now the project will fail without the patch i attached.

#6

Hello !

Fwiw, I’m considering just ripping out the compat layer (you can always just use 1.2 itself, and we can fix the problems that prevent them from coexisting).

Yes, Please !

+1 from me for removing it.

CU

#7

+1 from me for ripping out compat layer.On Wed, Nov 23, 2011 at 8:02 PM, Torsten Giebl wrote:

Hello !

Fwiw, I’m considering just ripping out the compat layer (you can always
just use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

Yes, Please !

+1 from me for removing it.

CU

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#8

+1 from me.

SDL 2.0 FTW.On Wed, Nov 23, 2011 at 1:12 PM, Dimitris Zenios <dimitris.zenios at gmail.com>wrote:

+1 from me for ripping out compat layer.

On Wed, Nov 23, 2011 at 8:02 PM, Torsten Giebl wrote:

Hello !

Fwiw, I’m considering just ripping out the compat layer (you can always
just use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

Yes, Please !

+1 from me for removing it.

CU

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#9

I agree that it’s a little confusing, and rather difficult to debug if it does wrong. Some people probably find it very useful though, I don’t know. Probably better to have a well documented list of changes between the two versions - there’s not all that much code that needs to be changed generally speaking: mainly the startup and shutdown in my experience.

#10

Yep, agreed.On Wed, 23 Nov 2011 13:15:07 -0600 Patrick wrote:

+1 from me.

SDL 2.0 FTW.

On Wed, Nov 23, 2011 at 1:12 PM, Dimitris Zenios <dimitris.zenios at gmail.com>wrote:

+1 from me for ripping out compat layer.

On Wed, Nov 23, 2011 at 8:02 PM, Torsten Giebl wrote:

Hello !

Fwiw, I’m considering just ripping out the compat layer (you can
always
just use 1.2 itself, and we can fix the problems that prevent them
from coexisting).

Yes, Please !

+1 from me for removing it.

CU

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#11

I put SDL_NO_COMPAT into the sources a LOOOOONG time ago… at least
a long time in terms of changes and patches. At the time it cut out
all the qOn Sun, Nov 20, 2011 at 11:52 AM, Vittorio Giovara <vitto.giova at yahoo.it> wrote:

Hi!
I was trying to compile SDL without the compatibility layer; I thought
that this could be achieved by defining SDL_NO_COMPAT but I found out
that several sections of sources won’t compile with it. I took my stab
at fixing this and created this patch:
http://dl.dropbox.com/u/24468/nocompat.patch however I’ve only tested
it against the ios build.

I often read that people added this symbol to their sources, would be
nice if they shared their mods.
Anyways is this patch good enough to be included in the sources?

thanks
Vittorio

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

#12

I put SDL_NO_COMPAT into the sources a LOOOOONG time ago… at least
a long time in terms of changes and patches. At the time it cut out
all the

GAAHHH! Hit the wrong key… Continuing…

1.2 entry points and as much of the actual 1.2 compatibility layer as
I could. As always happens the code has changed out from under the
ifdefs and it isn’t quite right any more.

Someone needs to really work it over again or else the compatibility
layer needs to be yanked out. I, for one, have been campaigning
against the compatibility layer since the start of coding for 1.3/2.0.
OTOH, the insistence on keeping 1.3 as compatible as possible with 1.2
has helped reduce the effect of second system syndrome on 1.3/2.0. So,
it is not all bad. But, now that the basic design has stabilized (if
not all the details) it is time for it to go.

IMO we should make sure that it is possible to write an API/ABI
compatible replacement for 1.2 as a not to thick layer on top of
1.3/2.0. But, that is not the same as maintaining 1.2 compatibility
inside of 1.3/2.0. It would make a nice project for someone who really
wanted to learn both APIs. But is not something that the core
developers should be spending time on. One serious problem with this
idea is that is could only support platform supported by 1.3/2.0 so
support of very old platforms would still depend on 1.2. OTOH, you
would, maybe? automagically, get 1.2 support on new platforms. A
feature that is likely to be of zero value to anyone.

Bob PendletonOn Wed, Nov 23, 2011 at 11:42 PM, Bob Pendleton <@Bob_Pendleton> wrote:

On Sun, Nov 20, 2011 at 11:52 AM, Vittorio Giovara <vitto.giova at yahoo.it> wrote:

Hi!
I was trying to compile SDL without the compatibility layer; I thought
that this could be achieved by defining SDL_NO_COMPAT but I found out
that several sections of sources won’t compile with it. I took my stab
at fixing this and created this patch:
http://dl.dropbox.com/u/24468/nocompat.patch however I’ve only tested
it against the ios build.

I often read that people added this symbol to their sources, would be
nice if they shared their mods.
Anyways is this patch good enough to be included in the sources?

thanks
Vittorio

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

–
±----------------------------------------------------------

#13

+1 of course :)On Wed, Nov 23, 2011 at 6:57 PM, Ryan C. Gordon wrote:

On 11/23/2011 10:02 AM, Vittorio Giovara wrote:

It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
mean is that right now the project will fail without the patch i attached.

Fwiw, I’m considering just ripping out the compat layer (you can always just
use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#14

I’ll be discussing this with Ryan. Originally the idea was for SDL 1.3 to
replace SDL 1.2, which means the compatibility layer was extremely useful
to minimize the pain with the transition.

At this point they serve two different audiences though, so it may make
sense to make a clean break.

At the moment SDL is almost entirely community supported, so I’d love to
hear from you guys which you’d prefer and (even better), why?

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release
is the distribution problem of how do you release system libraries of
SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL 1.3? Distributing SDL
1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to
make “2.0” versions of all the satellite libraries and make a clean break
there as well.

In terms of use case, there has been a lot of excitement about SDL 1.3 in
terms of licensing, since many people want to include SDL directly in their
projects instead of dynamically linking it. On the other hand, I’ve been
able to run some really old games on my computer that didn’t work, simply
by replacing the SDL library with a more recent one that supports the
system better.

I’m awake because I’m sick atm, so apologies if that didn’t come across
very well.

Thoughts?On Thu, Nov 24, 2011 at 3:27 AM, Vittorio Giovara < vittorio.giovara at gmail.com> wrote:

+1 of course :slight_smile:

On Wed, Nov 23, 2011 at 6:57 PM, Ryan C. Gordon wrote:

On 11/23/2011 10:02 AM, Vittorio Giovara wrote:

It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
mean is that right now the project will fail without the patch i
attached.

Fwiw, I’m considering just ripping out the compat layer (you can always
just
use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#15

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release
is the distribution problem of how do you release system libraries of
SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL 1.3? Distributing SDL
1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to
make “2.0” versions of all the satellite libraries and make a clean break
there as well.

My vote is to get rid of the COMPAT layer and bump the version number to
2.0, but then again I don’t use 1.2, so I think we should hear from the
guys that actually do use it. As to the satellite libraries, I don’t see
the advantage of bumping them to 2.0 if they remain compatible, as it is
now, with both SDL “core” 1.2 and 2.0, you get double the maintenance
issues in exchange for no gain?–
Gabriel.

#16

That’s the thing: they don’t remain compatible, in the binary sense at least, where SDL has made interface-level changes.? For example, SDL_Image loads graphic files and returns a SDL_Surface, but the definition of SDL_Surface changed from 1.2 to 1.3, which means SDL_Image needs to be recompiled with the new .h files from SDL 1.3 in order to work.________________________________
From: Gabriel Jacobo
To: SDL Development List
Sent: Wednesday, December 28, 2011 4:48 AM
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release is the distribution problem of how do you release system libraries of SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL 1.3? ?Distributing SDL 1.2 and 1.3 separately is fairly easy to do. ?Maybe the solution is just to make “2.0” versions of all the satellite libraries and make a clean break there as well.

My vote is to get rid of the COMPAT layer and bump the version number to 2.0, but then again I don’t use 1.2, so I think we should hear from the guys that actually do use it. As to the satellite libraries, I don’t see the advantage of bumping them to 2.0 if they remain compatible, as it is now, with both SDL “core” 1.2 and 2.0, you get double the maintenance issues in exchange for no gain?

?–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#17

Since SDL 1.3/2.0 allows static linking, it may be best to change the
default compile from dynamic to static, since that is the main issue (which
SDL library gets linked). This way, there is a distinct difference, and
may even justify doing the naming convention of libSDL1.3.a or libSDL2.0.a,
rather than libSDL.so, which is ambiguous to the version.
The same should happen to the adjacent libraries (SDL_Mixer, SDL_Image,
etc…).

Just my thoughts.
-AlexOn Wed, Dec 28, 2011 at 8:50 AM, Mason Wheeler wrote:

That’s the thing: they don’t remain compatible, in the binary sense at
least, where SDL has made interface-level changes. For example, SDL_Image
loads graphic files and returns a SDL_Surface, but the definition of
SDL_Surface changed from 1.2 to 1.3, which means SDL_Image needs to be
recompiled with the new .h files from SDL 1.3 in order to work.

From: Gabriel Jacobo
To: SDL Development List
Sent: Wednesday, December 28, 2011 4:48 AM
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release
is the distribution problem of how do you release system libraries of
SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL 1.3? Distributing SDL
1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to
make “2.0” versions of all the satellite libraries and make a clean break
there as well.

My vote is to get rid of the COMPAT layer and bump the version number to
2.0, but then again I don’t use 1.2, so I think we should hear from the
guys that actually do use it. As to the satellite libraries, I don’t see
the advantage of bumping them to 2.0 if they remain compatible, as it is
now, with both SDL “core” 1.2 and 2.0, you get double the maintenance
issues in exchange for no gain?

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#18

I’ll be discussing this with Ryan. Originally the idea was for SDL 1.3 to
replace SDL 1.2, which means the compatibility layer was extremely useful
to minimize the pain with the transition.

At this point they serve two different audiences though, so it may make
sense to make a clean break.

At the moment SDL is almost entirely community supported, so I’d love to
hear from you guys which you’d prefer and (even better), why?

I prefer 2.0 because that pretty much destroys any hope
for compatibility at the source/idiom level and leverages the freedom to
gut entire functions or poor design decisions. Imagine in Direct3D was
still stuck with execute buffers until D3D8…

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release
is the distribution problem of how do you release system libraries of
SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL 1.3? Distributing SDL
1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to
make “2.0” versions of all the satellite libraries and make a clean break
there as well.

That’s what I’d do.

In terms of use case, there has been a lot of excitement about SDL 1.3 in
terms of licensing, since many people want to include SDL directly in their
projects instead of dynamically linking it. On the other hand, I’ve been
able to run some really old games on my computer that didn’t work, simply
by replacing the SDL library with a more recent one that supports the
system better.

If SDL was say, LGPL, then at least for iOS, it wouldn’t help much: you
have to have a Mac, pay a $99 fee, and then you can relink the program.
It’s not impossible, just a lot of hurdles. I don’t really see value in
that. I’m all for liberal licensing because when people say “free
software”, I don’t want to hear “but”.On Wed, Dec 28, 2011 at 5:01 AM, Sam Lantinga wrote:

I’m awake because I’m sick atm, so apologies if that didn’t come across
very well.

Thoughts?

On Thu, Nov 24, 2011 at 3:27 AM, Vittorio Giovara < vittorio.giovara at gmail.com> wrote:

+1 of course :slight_smile:

On Wed, Nov 23, 2011 at 6:57 PM, Ryan C. Gordon wrote:

On 11/23/2011 10:02 AM, Vittorio Giovara wrote:

It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
mean is that right now the project will fail without the patch i
attached.

Fwiw, I’m considering just ripping out the compat layer (you can always
just
use 1.2 itself, and we can fix the problems that prevent them from
coexisting).

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#19

Agreed.? The (L)GPL bugs me.? It’s like Richard M. Ford telling you you can have your open-source in any color you want as long as it’s gray.________________________________
From: Patrick Baggett <baggett.patrick at gmail.com>
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

If SDL was say, LGPL, then at least for iOS, it wouldn’t help much: you have to have a Mac, pay a $99 fee, and then you can relink the program. It’s not impossible, just a lot of hurdles. I don’t really see value in that. I’m all for liberal licensing because when people say “free software”, I don’t want to hear “but”.

#20

My 2 cents is simply that we should have something that works and is featureful, at present the compatibility mode is not binary compatible which is what distributions would require to replace SDL
1.2 in a meaningful way, we either need real binary compatibility across the board or we need to use a separate base name (Linux distributions version their .so filenames but the includes remain
conflicted among other things, and other platforms do not share this versioned name system).

To summarize that, two options for the way forward:

  1. SDL2 / SDL2_mixer / SDL2_image / etc (or SDL_mixer2 / SDL_image2 if we prefer that naming scheme)
  2. direct replacement for existing libs with binary and source compatibility.

There aren’t other meaningful options from what I can see.

Both solutions are absolutely fine with me, I don’t personally see any problems with the existing SDL 1.2 API from a developer perspective, nor do I see a problem with the SDL 1.3 API from a developer
perspective (although at times it is a touch overblown - most apps will never need multiple windows at once and the existing SDL_SetVideoMode is all they ever dreamed of).

There are many little debates we can have over semantics, methodologies, theories and practical solutions, but this particular problem is a simple one with only those two solutions as I see it.On 12/28/2011 03:01 AM, Sam Lantinga wrote:

I’ll be discussing this with Ryan. Originally the idea was for SDL 1.3 to replace SDL 1.2, which means the compatibility layer was extremely useful to minimize the pain with the transition.

At this point they serve two different audiences though, so it may make sense to make a clean break.

At the moment SDL is almost entirely community supported, so I’d love to hear from you guys which you’d prefer and (even better), why?

As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release is the distribution problem of how do you release system libraries of SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL
1.3? Distributing SDL 1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to make “2.0” versions of all the satellite libraries and make a clean break there as well.

In terms of use case, there has been a lot of excitement about SDL 1.3 in terms of licensing, since many people want to include SDL directly in their projects instead of dynamically linking it. On
the other hand, I’ve been able to run some really old games on my computer that didn’t work, simply by replacing the SDL library with a more recent one that supports the system better.

I’m awake because I’m sick atm, so apologies if that didn’t come across very well.

Thoughts?

On Thu, Nov 24, 2011 at 3:27 AM, Vittorio Giovara <vittorio.giovara at gmail.com <mailto:vittorio.giovara at gmail.com>> wrote:

+1 of course :)

On Wed, Nov 23, 2011 at 6:57 PM, Ryan C. Gordon <icculus at icculus.org <mailto:icculus at icculus.org>> wrote:
> On 11/23/2011 10:02 AM, Vittorio Giovara wrote:
>>
>> It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
>> mean is that right now the project will fail without the patch i attached.
>
> Fwiw, I'm considering just ripping out the compat layer (you can always just
> use 1.2 itself, and we can fix the problems that prevent them from
> coexisting).
>
> --ryan.
>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier