Compiling ScummVM in Visual Studio 2013
Moderator: ScummVM Team
Compiling ScummVM in Visual Studio 2013
I'm trying to get the latest pull from Github up and running as a Visual Studio 2013 project. I'm currently getting linking errors. The build environment, since the documentation on building in VS was published, has seemed to have changed slightly. What I've done was directly link the include and lib directories to the external library paths, through right clicking scummvm and selecting the VC++ directory paths. Even though, VS recognizes the paths to the missing headers with intellisense, upon building I still receive a compile error. DO I have to add the includes and lib files through the linker and additional include directories directly? Where does $(SCUMMVM_LIBS) look by default? I'd rather not have to add all of the libs to VC's default lib and include directories, if I can avoid it. Thanks.
Re: Compiling ScummVM in Visual Studio 2013
It will only look where you pointed SCUMMVM_LIBS at.zerophase wrote:Where does $(SCUMMVM_LIBS) look by default?
Did you make sure you got all the additional libraries too (like FreeType2 and libjpeg)?
Also, if you want to get any really helpful response, you should usually post the specific error message(s) you are getting. Otherwise it's really hard to even see what goes wrong for you.
I haven't gotten FreeType2 or libjpeg yet, but I'm not getting those error messages yet. My specific error message is Error error C1083: Cannot open include file: 'theora/theoradec.h': No such file or directory
How can I go about pointing SCUMMVM_LIBS to a specific directory? I haven't used custom Visual Studio macros yet.
How can I go about pointing SCUMMVM_LIBS to a specific directory? I haven't used custom Visual Studio macros yet.
There are detailed instructions on how to set everything up for Visual Studio (including SCUMMVM_LIBS) in our wiki:
http://wiki.scummvm.org/index.php/Compi ... ual_Studio
http://wiki.scummvm.org/index.php/Compi ... ual_Studio
The team should integrate some info about compiling by VS2013, since create_project solution create v12 project files cointaning fluidsynth actived, talking about this row:
{"fluidsynth", "USE_FLUIDSYNTH", "libfluidsynth", false, "FluidSynth support" },
Since there is no FluidSynth libs into package libraries (neither 2013, nor 2015), it would be FALSE by default, but it will be 'true' instead if you try to build create_project solution.
Another thing is libpng16.lib by default into Additional Dependencies of Linker: no '16' version into 2013 libs package, so it would be set by default to 'libpng.lib'.
Can the team integrate this useful information? Thanks.
{"fluidsynth", "USE_FLUIDSYNTH", "libfluidsynth", false, "FluidSynth support" },
Since there is no FluidSynth libs into package libraries (neither 2013, nor 2015), it would be FALSE by default, but it will be 'true' instead if you try to build create_project solution.
Another thing is libpng16.lib by default into Additional Dependencies of Linker: no '16' version into 2013 libs package, so it would be set by default to 'libpng.lib'.
Can the team integrate this useful information? Thanks.
- dreammaster
- ScummVM Developer
- Posts: 555
- Joined: Fri Nov 04, 2005 2:16 am
- Location: San Jose, California, USA
There's several good things you point out.
First of all, as I mentioned just today in the IRC channel, the fluidsynth library doesn't come with a Visual Studio solution file. I'd previously tried to create one and build it, but it simply proved too difficult. So I added a disablement of the library to the create_msvc14.bat file, but didn't think to add it to MSVC12 as well. I'll take care of that tonight, unless someone else wants to do it in the interim. With that added, you won't have to worry about it any further.
Secondly, you're right about the name change of the png library. The older MSVC13 has it under the old name, but there should be no reason why you can't simply rename the library file. I'll put a note about that in the WIki when I can.
I'll also mention in closing that I've had some trouble running the newest version of the jpeg library on the wiki in the Starship Titanic engine. That's something that will have to be investigated further at some point as well.
First of all, as I mentioned just today in the IRC channel, the fluidsynth library doesn't come with a Visual Studio solution file. I'd previously tried to create one and build it, but it simply proved too difficult. So I added a disablement of the library to the create_msvc14.bat file, but didn't think to add it to MSVC12 as well. I'll take care of that tonight, unless someone else wants to do it in the interim. With that added, you won't have to worry about it any further.
Secondly, you're right about the name change of the png library. The older MSVC13 has it under the old name, but there should be no reason why you can't simply rename the library file. I'll put a note about that in the WIki when I can.
I'll also mention in closing that I've had some trouble running the newest version of the jpeg library on the wiki in the Starship Titanic engine. That's something that will have to be investigated further at some point as well.
This has nothing to do with SCUMMVM_LIBS (well, a little. but there's a better way):zerophase wrote:I haven't gotten FreeType2 or libjpeg yet, but I'm not getting those error messages yet. My specific error message is Error error C1083: Cannot open include file: 'theora/theoradec.h': No such file or directory
How can I go about pointing SCUMMVM_LIBS to a specific directory? I haven't used custom Visual Studio macros yet.
You need to set the "additional include directory" to where you put the theora header files, and the "additional library directory" to where your theora libs are. this setting is in the project properties.
Note that you should compile *all* required libraries yourself if you do your own build. MSVC has the nasty habit of generating different code depending on the default calling convention (cdecl, stdcall, fastcall, ...), runtime library selection (multithreaded/multithreaded-dll/multithreaded debug/multithreaded debug-dll) which are all incompatible with each other. You will keep getting linker warnings like "warning: use /nodefaultlib" or "Error: undefined symbol zlib_inflate@8" or something, and even if it links at the end, there's a good chance that your EXE will crash at some point. It will *definitely* crash if you mix debug and release libraries. This is why I hand-edit all static *.lib references for ScummVM beforehand, to link against the correct libraries (My naming convention is something like "theora_d_md.lib" instead of "theora.lib", the "_d" meaning debug build and the "_md" meaning multithreaded-dll)
Your build will only be perfect if you get no "use /nodefaultlib" warning at the end, which I consider quite some achievement
Note also that when compiling ZLIB you need to remove the ZLIB_WINAPI from the preprocessor definitions or it will not link with CDECL libraries/binaries later on.
Yes, it's annoying as hell but once you stop working against MSVC and accept its shortcomings, you'll learn to respect its advanced debugging techniques and the fast code it generates
- dreammaster
- ScummVM Developer
- Posts: 555
- Joined: Fri Nov 04, 2005 2:16 am
- Location: San Jose, California, USA
I did a review of the Wiki article, and it no longer has some of the old information about compiling for previous versions of Visual Studio that it used to have. So I'm a bit wary about re-introducing such information, particularly as it will become less and less likely that someone would be using it. Plus, we had to maintain a separate set of library files for it, as you noticed, since the format changed. Which would be an extra complexity in providing updated library files for it as well.
Thanks for reply.
I think that at least support for official previous version (VS2013, v12) could be maintained, since it's a lot used even at work by developers.
Moreover, you (the team) maintain the libraries version for previous (2013), and it won't be so different try to compiling still by VS2013 respect lastest 2015.
I think that at least support for official previous version (VS2013, v12) could be maintained, since it's a lot used even at work by developers.
Moreover, you (the team) maintain the libraries version for previous (2013), and it won't be so different try to compiling still by VS2013 respect lastest 2015.