VisualC.zip update

Hello,

The Visual Studio solutions and projects that are used to build SDL
under Windows have some problems. They are 32bit only and they have a
lot of stuff hard coded in them. Also, the instructions for using SDL
under Windows are not the “correct” ones IMHO.

So, basically I solved the issues with the build/test
solutions/projects. Compiling a 64bit build works, compiling 64bit
tests works, I removed all the hard coded stuff in them and replaced
it with Visual Studio environment variables. I also added
optimizations for release builds, removed compiler options that are no
longer current/necessary and cleaned the files. There was a lot of
stuff there that should not have been.

The catch is, the files only work with Visual Studio 2008 (that’s the
only thing I have on my sole Windows box), maybe you can make a
VisualC9.zip file or rename them or whatever.

Regarding the way SDL should be used in Windows, please look at how I
made the tests.sln solution. Basically the samples in there need SDL,
so the way I made it there is the way everyone that needs SDL should
do. You can see that I didn’t do anything but added the SDL and
SDLmain projects to the tests.sln solution, and set the 2 projects as
a dependency of the other projects (Solution properties -> Project
dependencies). You don’t have to worry about paths or anything, the
build system figures it out by itself. Another nice thing is that it
places a corresponding SDL.dll (debug/release and 32/64bit) in the
final build directory (where the executables go). Alternatively, you
could set the thing up, by going to project property page, under
Common Properties -> Frameworks and References, click on Add New
Reference and add the dependant project there.

If you choose to go with the pre-built binaries, and not compile SDL,
then you should do a meta project that does nothing but contain the
libs and the dll and set it up as above. Alternatively, you could
offer that empty project with the binary distribution.

You may wonder if having the same projects under multiple solutions is
a good idea, and the answer is yes. The “atomic” build unit is a
project, and a solution is nothing more but a description of the
relations between some projects, in such a way that it provides some
useful service.

I attached VisualC.zip. I used SDL-1.2.13.–
Aram H?v?rneanu
-------------- next part --------------
A non-text attachment was scrubbed…
Name: VisualC.zip
Type: application/zip
Size: 25471 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090409/26e94c0f/attachment.zip

I downgraded the solution and project files to VS2003, but only for
32-bit as 2003 has issues switching between 32- and 64-bit
configurations on the fly. For anyone using VS2005 it should
automatically upgrade them upon opening.

I found some information on setting up the different build environments
with 2003, so once I get a successful x64 environment I’ll post the
files. If anyone wants to have a go, much of what you need to do is just
change the version numbers. The only snag I ran into is the x64 platform
generating errors, but I assume that’s only due to the fact I don’t have
the x64 compiler on this machine.

  • Josh

Programmer – jstefanski at netdevil.com
Jumpgate Evolution – www.jumpgateevolution.com

Aram Havarneanu wrote:

Hello,

The Visual Studio solutions and projects that are used to build SDL
under Windows have some problems. They are 32bit only and they have a
lot of stuff hard coded in them. Also, the instructions for using SDL
under Windows are not the “correct” ones IMHO.

So, basically I solved the issues with the build/test
solutions/projects. Compiling a 64bit build works, compiling 64bit
tests works, I removed all the hard coded stuff in them and replaced
it with Visual Studio environment variables. I also added
optimizations for release builds, removed compiler options that are no
longer current/necessary and cleaned the files. There was a lot of
stuff there that should not have been.

The catch is, the files only work with Visual Studio 2008 (that’s the
only thing I have on my sole Windows box), maybe you can make a
VisualC9.zip file or rename them or whatever.

Regarding the way SDL should be used in Windows, please look at how I
made the tests.sln solution. Basically the samples in there need SDL,
so the way I made it there is the way everyone that needs SDL should
do. You can see that I didn’t do anything but added the SDL and
SDLmain projects to the tests.sln solution, and set the 2 projects as
a dependency of the other projects (Solution properties -> Project
dependencies). You don’t have to worry about paths or anything, the
build system figures it out by itself. Another nice thing is that it
places a corresponding SDL.dll (debug/release and 32/64bit) in the
final build directory (where the executables go). Alternatively, you
could set the thing up, by going to project property page, under
Common Properties -> Frameworks and References, click on Add New
Reference and add the dependant project there.

If you choose to go with the pre-built binaries, and not compile SDL,
then you should do a meta project that does nothing but contain the
libs and the dll and set it up as above. Alternatively, you could
offer that empty project with the binary distribution.

You may wonder if having the same projects under multiple solutions is
a good idea, and the answer is yes. The “atomic” build unit is a
project, and a solution is nothing more but a description of the
relations between some projects, in such a way that it provides some
useful service.

I attached VisualC.zip. I used SDL-1.2.13.



SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: VisualC.zip
Type: application/x-zip-compressed
Size: 23022 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090409/4ec1b925/attachment.bin

x64 support in Visual Studio 2003 is more like a hack (as in just use
64 bit compilers and tools instead of the default ones, no support for
dual development etc). I suggest dividing the thing in 2. Visual
Studio 6/Visual Studio 2003, 32 bit only. A dsw + dsp files for
project that can be upgraded to Visual Studio 2003, and a Visual
Studio 2005 sln + vcproj files with support for 64 bit that can be
upgraded to Visual Studio 2008.

Btw, I tested the VisualC.zip I attached in the first post with the
Intel compiler and it works like a charm :-).