Created attachment 1864 [details]
SVN patch off trunk HEAD to add MSVC++2008 project/solution files.

Created attachment 1865 [details]
Updated Files.

Updated the MSVC2008 .sln and .vcproj files.  Also added a directory for msvc libs to go (will upload them next).

Created attachment 1866 [details]
MSVC Libraries.

Prebuilt libraries compatible with MSVC++ 2008.  Place in code/libs/win32/msvc for attached project files to work correctly.

I think this is duplicated effort of bug 3771 and a bit more to maintain, i.e. custom-compiled .lib files.  Also, not sure what platforms it's been tested on.  Going by the instructions at http://wiki.ioquake3.org/Building_ioQuake3 I guess it's WinXP?

Anyway, my concern is that this isn't as generalized as a solution as the one in bug 3771 and would take more effort to update/maintain.

It appears that bug 3771 and this one are just different points of view as to what a source tree should contain.

My opinion is that a user should be able to checkout and build without having to do any setup outside of a normal OS install and compiler install.  I have heard it argued that even the compiler should be committed to the repository so the user only has to have an OS and the ability to acquire the source tree.

The approach taken in this bug is not quite that extreme but it does remove all dependencies besides the OS, IDE and DirectX SDK (which I'm fairly certain is required, though it comes with many IDE packages).

Bug 3771 takes the approach that only the minimum should be in the repository and the user is expected to go through a certain amount of setup work prior to being able to build the code they checked out.

The biggest complaint I have with the instructions linked to in 3771 is that it requires the user to place some libraries in their path (SDL) which can cause problems when you are dealing with multiple branches, multiple projects, etc. that require different versions of the same library.  I much prefer a solution that allows the user to keep each of their projects isolated from each other to avoid such problems with libraries.

Another potential solution would be to use SVN externals to point to remote source repositories for dependencies like SDL, curl, etc. and then create/add .vcproj and make files for those projects and add them to the various builds.  SVN externals also allow you to specify a certain revision of the external repository thus allowing ioQuake to depend on a specific version of SDL, curl, etc.  Of course, this only works if the dependencies use SVN as their source control system and it's publicly accessible.

Of course, perhaps it's the desire of the ioQuake maintainers to decrease the workload on the maintainers and instead increase the workload on the user/documenter/support personnel.  In my experience the maintainer, documenter and support personnel is usually the same person and offering increased simplicity to the user pays off in the end when compared to decreasing the work required by the maintainer.

All that said, I don't use ioQuake any longer so whichever route the maintainers of the project decide to take doesn't really affect me at all. :D

Sorry to Micah but I'd rather not take patches from somebody who "doesn't use ioQuake" which kind of belies the (lack of) motivation behind them, in my opinion. Anyway, I think 3771 and the assorted documentation produced in conjunction resolves the issue as stated in the subject and I thank Micah for the effort behind this. 

Please accept my apologies that it took so long to decide one way or the other.

*** This bug has been marked as a duplicate of bug 3771 ***