Replying now to the bug report as well, it was missing from the last couple of mails.
2015-05-31 0:20 GMT+01:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > 2015-05-30 21:27 GMT+01:00 Steve Clark <fawty...@gmail.com>: >> On Sat, 30 May 2015 10:14:31 +0100 >> "Manuel A. Fernandez Montecelo" <manuel.montez...@gmail.com> wrote: >> >>> Hello, >>> >>> 2015-05-29 15:54 GMT+01:00 Steve Clark <fawty...@gmail.com>: >>> > Package: libsdl-stretch-dev >>> > Version: 0.3.1-4 >>> > >>> > Including the SDL_stretch header file causes the following compile >>> > error: >>> > /usr/include/SDL_stretch/SDL_stretch.h:25:23: fatal error: >>> > SDL_video.h: No such file or directory #include "SDL_video.h" >>> > >>> > This is because the SDL stretch header files are in a separate >>> > directory. >>> > >>> > There are 2 possible solutions: >>> > 1. The SDL stretch header files should be in /usr/include/SDL with >>> > the other SDL files >>> > >>> > 2. Comment the offending line out in SDL_stretch.h >>> > >>> > Option 2 is tested as workable because the header file continues >>> > with: #ifndef _SDL_video_h >>> > #include <SDL/SDL_video.h> >>> > #endif >>> > ... which means it will still work. But I think option 1 is >>> > preferable. >>> > >>> > I don't know if this is an upstream bug. But as it stands, it >>> > unusable unless that line is commented out. >>> >>> Doesn't it work if you pass "-I/usr/include/SDL" (the first letter is >>> a capital 'i', not an L) to the compiler? >>> >>> >>> Cheers. >> >> Yes it does. But I shouldn't have to do that. > > As far as I am aware, it's a common practice to have library headers > installed in different subdirectories of /usr/include (or under > /usr/local/include, or /opt, or different paths of the user's > home...), and then when compiling a project that needs another library > included, to pass the -I option to the compiler. > > SDL_stretch is not a part of the main SDL modules, it comes from a > different upstream, and they decided to install it in a different path > rather than in the same directory as other SDL modules. > > The Debian package does not modify the installation path coming from > upstream, so probably the situation is the same in other > distributions. Even within Debian, this has been the behaviour for > many years, probably more than a decade by now, so moving the files to > another path is not a good solution, I think -- it will affect the > other users. > > On the other hand, the following code looks a bit problematic, because > as it is happening to you right now, if the first #include fails the > whole compilation fails, it is a fatal error to include a file and the > file not being there, so those four lines do not make much sense. > > #include "SDL_video.h" > #ifndef _SDL_video_h > #include <SDL/SDL_video.h> > #endif > > > The las version is from 6 years ago and this project has not been > adapted for SDL2, so it makes me wonder if the project is still alive > and if they will consider to fix it and give some advice on what to do > in this case. > > I cannot do that at the moment, I will try at some point in summer if > I find the time, but if in the meantime you or anybody else get in > contact with upstream, please drop a line here. > > > Cheers. > -- > Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org