Proposal to change includes to <SDL/SDL.h>

SDL Development
1

Hi,

Looking at SDL_image I noticed that all code in there is in this form

#include “SDL.h”

And you probably all know that the SDL headers are installed in

/include/SDL

To complete the story, we have sdl-config --cflags for use at compile
time. It works, but it is ugly when you want to build and use frameworks
and Xcode. In an Xcode project you have to list the directory where
SDL.framework is, but you also have to fully specify where the Headers
directory (in that framework) is. If you want to build with another
SDL version (different location of the framework), you have to modify
the INCDIRs too.

What I am proposing (for SDL 1.3 of course) is to use the following include
statement

#include <SDL/SDL.h>

(Using <> also makes more sense than using “”.)

What is needed to make this happen?

  1. change sdl-config.in (just drop the /SDL from -I at includedir@)
  2. no further changes needed in SDL
  3. change the users of SDL (i.e. SDL_image, examples, etc)

During a certain migration time we may want to change sdl-config.in to have
both directories.
echo -I at includedir@ -I at includedir@/SDL @SDL_CFLAGS@

What do you think?

BTW. I have a patch for SDL_image with the “SDL.h” => <SDL/SDL.h>
changes.–
Kees

2

I personally like this strategy, and if I was only doing SDL
1.3/2.0/whatever final version gets picked, it would be cool, but I can tell
you right now that the first error someone gets when porting their code is
having to fix #include errors all of the place. Not the most pleasant first
experience with the “new” SDL. Still, that isn’t a good long term
justification, just something to consider.

I like the use of a separate folder for SDL stuff because I think that is
just cleaner, but it is going to be a pain to get Linux distros to handle
dual SDL 1.2 / SDL 1.3 support. They would need a different pkgconfig file
for them, and would need to make sure that /usr/include is not messed up,
e.g:

/usr/include/SDL-1.2/ <- SDL 1.2, pkgconfig gives
-I/usr/include/SDL-1.2
/usr/include/SDL-1.3/ <- SDL 1.3, pkgconfig gives
-I/usr/include/SDL-1.3

I can imagine there will be at least one Linux distro that will royally
screw this up and mix 1.2 and 1.3 headers because they don’t apply a version
number to the SDL folder and just throw all of SDLs headers into
/usr/include/SDL and have pkgconfig give -I/usr/include/SDL.

So yes, I approve, but in reality, I expect a lot of distros to screw this
up. Be ready to handle the fallout. :frowning:

PatrickOn Thu, Aug 4, 2011 at 4:28 PM, Kees Bakker <kees.bakker at xs4all.nl> wrote:

Hi,

Looking at SDL_image I noticed that all code in there is in this form

#include “SDL.h”

And you probably all know that the SDL headers are installed in

/include/SDL

To complete the story, we have sdl-config --cflags for use at compile
time. It works, but it is ugly when you want to build and use frameworks
and Xcode. In an Xcode project you have to list the directory where
SDL.framework is, but you also have to fully specify where the Headers
directory (in that framework) is. If you want to build with another
SDL version (different location of the framework), you have to modify
the INCDIRs too.

What I am proposing (for SDL 1.3 of course) is to use the following include
statement

#include <SDL/SDL.h>

(Using <> also makes more sense than using “”.)

What is needed to make this happen?

  1. change sdl-config.in (just drop the /SDL from -I at includedir@)
  2. no further changes needed in SDL
  3. change the users of SDL (i.e. SDL_image, examples, etc)

During a certain migration time we may want to change sdl-config.in to
have
both directories.
echo -I at includedir@ -I at includedir@/SDL @SDL_CFLAGS@

What do you think?

BTW. I have a patch for SDL_image with the “SDL.h” => <SDL/SDL.h>
changes.

Kees

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

3

Personally I don’t like dependency on things like pkgconfig. They
don’t always work or are not portable for every build system (like
some graphical IDEs).
For me, any non-trivial library (more than one include file) should be
on it’s own directory, and incompatible versions have their own
directory.

I really don’t see any point in the new SDL version to be called SDL
1.3. It’s a major incompatible release, so make it 2.0 and just put
it’s headers on “/SDL2”.
The same for the librariers: just name them “libSDL2.so”, “SDL2.dll”, etc.

Any program should specifically include <SDL/SDL.h> or <SDL2/SDL.h>. A
program that adds “/SDL” or “/SDL2” to it’s include
path just to save a bit on the typing deserves the pain…

If there really is a strong request to make a compatibility layer, do
it as a separate “compat” library. It will install "/SDL"
headers and a libSDL library with wrappers to SDL2, and only if the
system doesn’t already have the original 1.2 version installed.

This compatible layers are never foolproof. Usually have a lot of
bugs, because no one is terribly interested in making them 100%
correct, and it’s open source so no “boss” to order one to make a
decent job.
One good example of this was the libusb 0.xx compatibility library
(wrapper for libusb-1.0), which worked ok for some, not working at all
for many. It’s a waste of time when one can just install the older
version of the library.

I would go even far and also make sure the API had no name collisions
with the SDL 1.2 API, but that can be considered too much. It has the
advantage of making it possible to link with both at the same time,
but having to rename every function and constant to SDL2_* may be
considered too pedantic, and can be solved with dynamic linking (as
long as they are not both linked at the same time, which I don’t have
any good reason to do for this particularly library).

Regards,
~Nuno Lucas

4

This could potentially work, having both SDL and SDL2 include and lib
folders will prevent any linking issues or compilation problem.
Of course it will require the removal of the sdl_compat layer, but i
was under the impress that there was a general consensus in removing
it, am i right?

Best
VittorioOn Fri, Aug 5, 2011 at 12:45 AM, Nuno Lucas wrote:

Personally I don’t like dependency on things like pkgconfig. They
don’t always work or are not portable for every build system (like
some graphical IDEs).
For me, any non-trivial library (more than one include file) should be
on it’s own directory, and incompatible versions have their own
directory.

I really don’t see any point in the new SDL version to be called SDL
1.3. It’s a major incompatible release, so make it 2.0 and just put
it’s headers on “/SDL2”.
The same for the librariers: just name them “libSDL2.so”, “SDL2.dll”, etc.

Any program should specifically include <SDL/SDL.h> or <SDL2/SDL.h>. A
program that adds “/SDL” or “/SDL2” to it’s include
path just to save a bit on the typing deserves the pain…

If there really is a strong request to make a compatibility layer, do
it as a separate “compat” library. It will install "/SDL"
headers and a libSDL library with wrappers to SDL2, and only if the
system doesn’t already have the original 1.2 version installed.

This compatible layers are never foolproof. Usually have a lot of
bugs, because no one is terribly interested in making them 100%
correct, and it’s open source so no “boss” to order one to make a
decent job.
One good example of this was the libusb 0.xx compatibility library
(wrapper for libusb-1.0), which worked ok for some, not working at all
for many. It’s a waste of time when one can just install the older
version of the library.

I would go even far and also make sure the API had no name collisions
with the SDL 1.2 API, but that can be considered too much. It has the
advantage of making it possible to link with both at the same time,
but having to rename every function and constant to SDL2_* may be
considered too pedantic, and can be solved with dynamic linking (as
long as they are not both linked at the same time, which I don’t have
any good reason to do for this particularly library).

Regards,
~Nuno Lucas

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

5

Looking at SDL_image I noticed that all code in there is in this form

?#include “SDL.h”

And you probably all know that the SDL headers are installed in

/include/SDL

Are they? Not on my system.

Also see: http://wiki.libsdl.org/moin.cgi/FAQDevelopment#Do_I_.23include_.3CSDL.h.3E_or_.3CSDL.2BAC8-SDL.h.3E.3F

6

Virrorio and Nuno,

I agree that the next release of SDL should be named SDL2, and
work like Nuno suggests. It should probably drop the compatibility wrapper too.

Kind Regards,

B.

7

+1On 05/08/2011 14:22, Beoran wrote:

I agree that the next release of SDL should be named SDL2, and
work like Nuno suggests. It should probably drop the compatibility
wrapper too.

8

Op 2011-08-05 12:28 , Brian Barrett schreef:

Looking at SDL_image I noticed that all code in there is in this form

#include “SDL.h”

And you probably all know that the SDL headers are installed in

/include/SDL
Are they? Not on my system.
What system is that?

Also see: http://wiki.libsdl.org/moin.cgi/FAQDevelopment#Do_I_.23include_.3CSDL.h.3E_or_.3CSDL.2BAC8-SDL.h.3E.3F

I don’t know how wrote that, but I get the impression that this person
does not know the difference between “SDL.h” and <SDL.h>

The “SDL.h” is to include a (local) project header, and the <SDL.h> is
to include
a “system” header.

And I also want to point to Makefile.in of SDL where you’ll find this:
install-hdrs: update-revision
$(SHELL) $(auxdir)/mkinstalldirs $(DESTDIR)$(includedir)/SDL
for file in $(HDRS); do
$(INSTALL) -m 644 $(srcdir)/include/$$file
$(DESTDIR)$(includedir)/SDL/$$file;
done

And so (at least on Ubuntu, MacOS-Fink) you’ll find the headers in
…/include/SDL–
Kees

9

The “SDL.h” is to include a (local) project header, and the<SDL.h> is
to include a “system” header.

It may come as a surprise to Linux users, but SDL is not a "system"
header on most platforms.

–ryan.

10

Op 2011-08-04 23:51 , Patrick Baggett schreef:

I personally like this strategy, and if I was only doing SDL
1.3/2.0/whatever final version gets picked, it would be cool, but I
can tell you right now that the first error someone gets when porting
their code is having to fix #include errors all of the place. Not the
most pleasant first experience with the “new” SDL. Still, that isn’t a
good long term justification, just something to consider.
Yeah, I’m afraid you’re right.

I like the use of a separate folder for SDL stuff because I think that
is just cleaner, but it is going to be a pain to get Linux distros to
handle dual SDL 1.2 / SDL 1.3 support.
The headers are already in a separate folder on Linux: /usr/include/SDL
They would need a different pkgconfig file for them, and would need to
make sure that /usr/include is not messed up, e.g:

/usr/include/SDL-1.2/ <- SDL 1.2, pkgconfig gives -I/usr/include/SDL-1.2
/usr/include/SDL-1.3/ <- SDL 1.3, pkgconfig gives -I/usr/include/SDL-1.3
Pkgconfig? Right now we have sdl-config, for both SDL1.2 and SDL1.3. I
think pkgconfig came up recently. Which platforms use pkgconfig?

I can imagine there will be at least one Linux distro that will
royally screw this up and mix 1.2 and 1.3 headers because they don’t
apply a version number to the SDL folder and just throw all of SDLs
headers into /usr/include/SDL and have pkgconfig give -I/usr/include/SDL.

So yes, I approve, but in reality, I expect a lot of distros to screw
this up. Be ready to handle the fallout. :frowning:
Let’s see where we can get.–
Kees

11

Op 2011-08-06 10:50 , Ryan C. Gordon schreef:

The “SDL.h” is to include a (local) project header, and the<SDL.h> is
to include a “system” header.

It may come as a surprise to Linux users, but SDL is not a “system"
header on most platforms.
Still, it certainly doesn’t fall in the category where you would use
"SDL.h”. SDL is installed
(on most platforms) in /usr or /usr/local and the like. In that sense I
was calling it “system”.
(( Installed with a package manager of some sort. ))

The “SDL.h” syntax I would only use when the code is merged into your
project tree. Hardly
anybody does that.–
Kees