About env variable SCUMMVM_LIBS and SDL.h

[monsieurouxx]

Hi,

I'm trying to compile ScummVM following a procedure with as few steps as possible:

• I've downloaded the package you made containing the compiled libraries, and put it in <mylibfolder>
• I've created a Code::Blocks project using the create_project tool. It seems to be properly set up, with the "search directories" containing $(SCUMMVM_LIBS)\include
• I try to build the project
  
  It turns out that SDL.h can't be found.
  
  I'm not sure if it's normal, but SDL.h is in %SCUMMVM_LIBS/include/SDL , not in %SCUMMVM_LIBS/include
  That would explain why the file cannot be found.
  Should I change that manually, or is it normal?

[LordHoto]

Hi,

I'm trying to compile ScummVM following a procedure with as few steps as possible:

• I've downloaded the package you made containing the compiled libraries, and put it in <mylibfolder>
• I've created a Code::Blocks project using the create_project tool. It seems to be properly set up, with the "search directories" containing $(SCUMMVM_LIBS)\include
• I try to build the project
  
  It turns out that SDL.h can't be found.
  
  I'm not sure if it's normal, but SDL.h is in %SCUMMVM_LIBS/include/SDL , not in %SCUMMVM_LIBS/include
  That would explain why the file cannot be found.
  Should I change that manually, or is it normal?

You should probably put %SCUMMVM_LIBS/include/SDL into the include path. It is pretty common standard only to include <SDL.h>. This is since "sdl-config --include" will automatically add the SDL directory to the include search path. Also on some systems the libraries are not placed in a dir called "SDL", but "SDL-1.2", I think it was like that on FreeBSD for example.

[monsieurouxx]

You should probably put %SCUMMVM_LIBS/include/SDL into the include path. It is pretty common standard only to include <SDL.h>. This is since "sdl-config --include" will automatically add the SDL directory to the include search path. Also on some systems the libraries are not placed in a dir called "SDL", but "SDL-1.2", I think it was like that on FreeBSD for example.

You keep talking about UNIX You always do that. Like you're trying to cast some curse on me.
I'm using Windows.
I'm just surprise that "create_project" does not add SDL/include to the compiler's paths, as it's its job. I just thought I should report.

[LordHoto]

You should probably put %SCUMMVM_LIBS/include/SDL into the include path. It is pretty common standard only to include <SDL.h>. This is since "sdl-config --include" will automatically add the SDL directory to the include search path. Also on some systems the libraries are not placed in a dir called "SDL", but "SDL-1.2", I think it was like that on FreeBSD for example.

You keep talking about UNIX :) You always do that. Like you're trying to cast some curse on me.
I'm using Windows.
I'm just surprise that "create_project" does not add SDL/include to the compiler's paths, as it's its job. I just thought I should report.

I don't exclusively talk about UNIX, I just explained why we include <SDL.h> and not <SDL/SDL.h>, in case you are wondering why. On the other hand you exclusively complain about when I answer your questions with information on how to do stuff. Let's take your first how to compile create_project question, you said you use MinGW and used make in an incorrect way, so I only said what you need to do to use it. I can not help that you simply ignore(d) the fact that you need to run configure to use the default build system, which is also used for MinGW. In general MinGW aims to provide a UNIX-style enviorment for building, that is why there is MSYS with a bash etc. So configure is not necessarily limited to UNIX, since it works just fine on Windows (given you have the correct tools installed). Anyway I am wondering about why I still answer your questions when you start like this in every (second) reply.

Anyway back to the code::blocks project files: I am not suprised create_project does not add include/SDL (or SDL/include whatever, I am not sure how your libraries are installed). First of all there is nobody using code::blocks, next I do not think it is tested well, third I would not consider code::blocks being officially supported and last but not least: it might be that the people/person who used code::blocks in the past had a different library layout, thus it is pretty obvious why it does not add exactly the path you need to the include path.

[monsieurouxx]

You keep talking about UNIX You always do that. Like you're trying to cast some curse on me.

I don't exclusively talk about UNIX, I just explained (...)

Hey, that was meant to be a joke.
About the configure thing: I thought that was only for UNIX... That's why I ignored it! Sorry if I offended you in any way.

Anyway back to the code::blocks project files: (...) I would not consider code::blocks being officially supported and last but not least: it might be that the people/person who used code::blocks in the past had a different library layout

Well that explains pretty much everything...
I'm on Windows and I can't install VisualC++, so I'm pretty screwed, but that's not your fault.

[Julien]

As of r55345, compilation and linking from inside the Code::Blocks IDE should work.

It still requires a bit of manual work since the paths to the precompiled libs are shared between all project types.

The created workspace is expecting the same folder hierarchy as can be found in the MSVC precompiled libraries package and the same library names (apart for zlib).

Mingw compiled libraries should go to lib/mingw and the following set of files renamed:
- libFLAC.a to libFLAC_static.a
- libogg.a to libogg_static.a
- libtheora.a to libtheora_static.a
- libvorbisfile.a to libvorbisfile_static.a
- libz.a to libzlib.a

Let me know if you still have problems with compilation inside Code::Blocks after the changes.

[monsieurouxx]

Mingw compiled libraries should go to lib/mingw and the following set of files renamed:
- libFLAC.a to libFLAC_static.a
- libogg.a to libogg_static.a
- libtheora.a to libtheora_static.a
- libvorbisfile.a to libvorbisfile_static.a
- libz.a to libzlib.a

That's exactly what I was in the middle of doing, discovering by myself, so your post is a real blessing.
- I got the "_static" thing. But it's the opposite, I believe. You have to remove "_static" from the names.
- zlib is also OK. I've fed the path to the zlib library manually (therefore I didn't have to change the name - different solution, same result).
- same thing for sdl.a : I had to give the full path. For some strange reason, SDL.a is not detected.

But I still have questions :

1/ opengl32.a and winmm.a. EDIT: Provided by the compiler, in CodeBlocks/MiGW

2/ why do you say I have to move the libraries to SCUMMVM_LIBS/lib/mingw? I believe they're already in the right path. Am I wrong?

3/ The compiler complains that <scummvm>/common/scalers/hq2x_i386.o and /hq3x_i386.o are not there. Since they're added by a module.mk when USE_NASM is enabled, I have commented them out, but that's not a good idea as then I have undefined references (e.g. "hq2x_16") and I'm pretty sure that's the cause.

4/ SDL doesn't work so well. I have plenty of undefined references... I've downloaded the latest SDL devl for minGW32, but there is only libSDL.la, not SDL.a. But anyway it's SDL 1.2.14, whic is already the one included in the package with all libraries from the Wiki page, i.e. the one I'm using. I don't understand why there are those undefined references.


What do you think ?