littleflylongbow / guichan

Automatically exported from code.google.com/p/guichan
Other
0 stars 0 forks source link

Support for PSP platform (pspsdk from www.ps2dev.org) #23

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I'm trying to port guichan to PSP, but I have some issues doing it.

The first is that includes for SDL.h are wrong. You're using "SDL.h" 
where the correct is <SDL/SDL.h>. (I worked around this by including full 
SDL path.. but its wrong)

I already worked on configure.in and config.sub to support psp toolchain. 
But now, I'm having problems to get guichan dist-files to detect 
correctly PSP SDL, SDL_image and OpenGL.

Original issue reported on code.google.com by danny.gr...@gmail.com on 16 Nov 2007 at 10:29

Attachments:

GoogleCodeExporter commented 8 years ago
It's not wrong to include "SDL.h", read this:
http://libsdl.org/faq.php?action=listentries&category=2#19

You are supposed to check where SDL.h is installed with sdl-configure as it can 
be
installed on different locations on different platforms, hence including a full 
path
like #include <SDL/SDL.h> is wrong.

Original comment by olof.nae...@gmail.com on 22 Nov 2007 at 6:24

GoogleCodeExporter commented 8 years ago
most of popular systems (e.g. windows mingw and I suppose all linux kinds) 
stores
SDL.h under SDL directory and #include <SDL/SDL.h> works fine with them.

Using #include "SDL.h" only incorporates inconveniences using the software in 
systems
for which #icnlude <SDL/SDL.h> would work without any adjustments.

It would be good to change "SDL.h" to <SDL/SDL.h>, just a suggestion.

Original comment by igagis@gmail.com on 11 Mar 2008 at 3:24

GoogleCodeExporter commented 8 years ago
I think the SDL FAQ entry is quite clear on how to include SDL. As Olof said, 
you're
supposed to use sdl-config to find out what to add your include path. Its 
output on
my system is for example:

$ sdl-config --cflags
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT

Which means that if SDL would be in any other place than /usr/include (which the
compiler happens to checks by default), then "#include <SDL/SDL.h>" won't even 
work.
Don't make life more complicated for those who follow the conventions.

Original comment by b.lindeijer on 11 Mar 2008 at 4:12

GoogleCodeExporter commented 8 years ago
not all systems has sdl-config (e.g. Win32)

And in case of "SDL.h" we should manually write -Isome/absolute/path/SDL in 
compiler
keys. I do not know, maybe most systems store SDL headers in some other place 
than in
SDL/ subfolder, but all I have seen stores in ..../SDL/. So, the inconvenience 
is
using too much side dependancies like sdl-config or manually typing 
-I.../path/SDL.

While in the othe hande we could simply type <SDL/SDL.h> and it would work on
majority of system, but where it will not we could manually write a path to it.

Anyway, it is just a suggestion, I'm not insisting.

Original comment by igagis@gmail.com on 18 Mar 2008 at 8:57

GoogleCodeExporter commented 8 years ago
But the thing is, sdl-config is just a tool for end-users to find the SDL 
headers and
not something Guichan should rely on, Guichan should rely on the end user 
providing
the correct path (of course we can make that process very simple if sdl-config 
is
present). As the SDL headers can be installed anywhere (especially on a Windows
system) the best approach is to include "SDL.h" as it will always work given 
that the
end user supplies the correct path to the compiler. Including <SDL/SDL.h> might 
work
on some system but also might break on others as it forces the headers to 
reside in
an SDL directory.

You cannot manually write a path to the SDL headers if we force the headers do 
not
reside in an SDL directory, it would require a symlink or some other horrible 
hack.

Original comment by olof.nae...@gmail.com on 24 Mar 2008 at 9:31