Created attachment 1859 [details]
\misc\msvc\quake3.vcproj

This is the updated project file.  Wewt!

Created attachment 1923 [details]
Updated project file

Updated to include default VOIP support, compiling without dependencies on external MS runtime libraries.

Created attachment 1924 [details]
build instructions for mingw for "misc" folder

This is a copy of my how-to guide in the forums for creating and successfully building ioquake using mingw.  I figure it might be handy to have it in the "misc" folder as it's small and it hopefully means less questions from people.

Created attachment 1925 [details]
build instructions for visual studio 2005 for "misc" folder

Again, intended for the "misc" folder, setup and build instructions for the Visual Studio 2005 environment.

Created attachment 1926 [details]
build instructions for visual studio 2008 for "misc" folder

Same thing, this time specific for Visual Studio 2008.  Again intended for the "misc" folder.

This is similar to bug 3779 ( https://bugzilla.icculus.org/show_bug.cgi?id=3779 ) with the exception that I have no idea what that bloke is doing.  It seems to be building off the instructions he created on the wiki at http://wiki.ioquake3.org/Building_ioQuake3 but again, I'm hazy as to what he's doing there.  DirectX SDK isn't needed nor are .lib files to be included in the source tree?  The only two .lib files I found I needed to get elsewhere were two SDL libs, though I don't know if you want to bother including those.  He's got curl, openal, zlib, and something else I don't know (efx-util?).  

I haven't looked into the project file he has, but the VS2005 project file in my patch has been tested to work with VS2005 and VS2008 on Win2K and WinXP coming from fresh OS install and compiler install to finished compile (hooray for VMs!)

Here are the step-by-step guides I generated while trying to figure out how to compile ioq3 fresh from SVN, for reference:

http://ioquake.org/forums/viewtopic.php?f=12&t=55
http://ioquake.org/forums/viewtopic.php?f=12&t=60

I will probably migrate those to the wiki sometime as well.  The quake3.vcproj file basically eliminates the "setting up the compiling environment" section of those instructions.

(In reply to comment #6)
> I haven't looked into the project file he has, but the VS2005 project file in
> my patch has been tested to work with VS2005 and VS2008 on Win2K and WinXP
> coming from fresh OS install and compiler install to finished compile (hooray
> for VMs!)

That appears not to be the case (at least, with SVN rev 1489). That bug seems to be trying to resolve the same build issues I have - ioq3 depends on a number of 3rd party libs which are not included, ie:
- OpenAL
- libcurl
- SDL

The USE_LOCAL_HEADERS option pulls in the headers from the ioquake3 dir, but as the .lib files are not in the SVN so you cannot link unless you independently find the appropriate .lib's from the 3 above projects.

Note that the USE_LOCAL_HEADERS option is not currently used in the MSVC project. It's also broken at the moment as it doesn't have the correct paths to local files, so it defaults to searching system folders anyway (see patch).

As a final gotcha, the rename of jpeg-6 to jpeg-6b hasn't been updated in the MSVC project (see patch).

Created attachment 1948 [details]
Patch for MSVC project for the jpeg-6 -> jpeg-6b rename

Created attachment 1949 [details]
Patch for USE_LOCAL_HEADERS - specify the paths to the "local" headers so that it can find them

> As a final gotcha, the rename of jpeg-6 to jpeg-6b hasn't been updated in the
> MSVC project (see patch).

Checking the versions in this bug, I see that we've duplicated some effort here, and that you've made other changes - like defining the USE_LOCAL_HEADERS constant - my patches were relative to SVN head, not this bug, as I only checked the bugzilla after successfully building...

Your vcproj still references openal32.lib SDLMain.lib, SDL.lib, libcurl.lib etc though, so the main issue of needing to go find these elsewhere is still an open issue.

Aye, the updated project file I provided is meant to be used in conjunction with the how-to-build instructions also attached, which is why you still need to get the SDL lib.  Going by these instructions:  

http://ioquake.org/forums/viewtopic.php?f=12&t=55

...I recall that I only had to get the SDL lib, not openAL or libCURL.  Also, I could have sworn I did that JPEG rename.  I have SVN blocked here so I'll have to wait until I get home to try a fresh SVN grab and maybe I'll start from a fresh VM (XP SP3) and install the SDK and VS2005 just to see what's goin' on.

Also, I'm not sure you addressed the VOIP compile?  There's a missing .h file that blocked me from elegantly (?) including Speex that I had to snag and that is referenced in bug 3857, http://bugzilla.icculus.org/show_bug.cgi?id=3857

I highly appreciate the extra set of eyes as Visual Studio stuff seems to be the bastard child of opensource, i.e. no one really cares about it or cares about getting it working as long as "make" works and the included makefile does its magic for *nix.  

Please take a look at some of the step-by-step instructions I wrote and see if it makes sense to you, or if I'm going about this in a funky way that no one would ever do.  I had to pick this up as I went along and don't use Visual Studio on a daily basis.  

The included .lib files didn't seem to be an issue when I compiled, BTW, the only one I had to go out and find was sdl.lib--the rest didn't complain.  Now I don't know if that means that VS just silently failed to compile the project properly, but given how many other random warnings it likes to throw, I don't think that's the case.

Again, thanks for taking a look at this bug and the project file!

Actually, now that I think about it, the reason I didn't have to find some of the other libs is probably due to this:

10) Additional Include Directories should include: ..\..\code\SDL12\include; ..\..\code\libcurl; ..\..\code\AL; ..\..\code\libspeex\include

So I'm building curl and openal from the ioq3 source directly, though I guess it didn't work for SDL...?

It could be that VS builds the .lib's temporarily from the include directories FIRST, then when it starts linking and whatever, it uses those generated ones when it tries to match up the openal.lib and libcurl.lib, etc.

I've now figured out how come you do not need OpenAL or libcurl .lib files - I think you've got USE_OPENAL_DLOPEN and USE_CURL_DLOPEN defined (although in the attached project only the curl one is defined, and not in all configurations - some still have libcurl.lib in Additional Dependencies in linker settings).

The other possibilities are that you're building them from source, and have them marked as a dependent project (in which case, MSVC automatically links with the output), or that you've got them somewhere in a system search path.

MSVC doesn't fail silently if referenced libs aren't found btw, it refuses to link.

I didn't find the voip errors because the SVN version of the project is outdated compared to the one in this bug, so I didnt even have the USE_VOIP option defined, and for my purposes I didn't even notice that voip was missing. 

Ok, I finally had a chance to check things out.  SVN 1492, fresh into a new directory.  I then snagged the quake3.vcproj file from this bug and overwrote the one in /misc that was in SVN.  I also got the config.h from bug 3857 for /libspeex, fired up VS2008 on WinXP SP3, and it compiled just fine.  Well, lots of type mismatch warnings and the UI module didn't compile, but that's "normal" with VS2008.  No problems with JPEG and USE_LOCAL_HEADERS is already defined.  

I'm guessing you snagged the quake3.vcproj from SVN and were modifying that or thought that that one was supposedly the "fixed" one I provided?  This bug has yet to be committed so the SVN project files are pretty old.  Also, it seemed that just modifying the "quake3" project as part of the overall ioq3 "solution" was enough to get VS2008 (and VS2005) to compile just right.  Maybe the cgame, q3_ui, and ui projects didn't need the same dependencies and so haven't needed tweaking in 3+ years, I dunno.  I figured it they weren't broke, don't fix 'em!

For someone evaluating this bug for inclusion, I'd recommend ignoring the two patches that Mr. Jacques submitted as I think they were made based on the quake3.vcproj in SVN, not based on the quake3.vcproj I attached to this bug.  Unless my assumption is wrong and there's just something really hosed up?  But I think that's what happened--wrong quake3.vcproj was assumed to be "fixed".

so could someone create a final patch that does everything needed? No files that need to be copied somewhere, just a unified diff that can be applied easily.

I'll hop on IRC sometime and try to sucker someone into walking me through making a diff.  The contents of this bug are 1 VS2005 project file and 3 text files; the text files are additional files that did not previously exist in SVN and are intended to be instructions just sitting in the "misc" folder and only maintained if something drastic changes.  I don't know that there's anything to diff against for those three files.  For the quake3.vcproj file I can probably figure out how to make a diff rather than just a replacement, though I know I'll need someone to help with what KIND of diff y'all are wanting as I think last time I used a tool to make a unified diff and was told that I did it wrong or somethin'.

Created attachment 1957 [details]
unified diff between svn 1302 and the new hotness

Unified diff, hopefully this is correct.  If someone with VS2005 or VS2008 and either platform sdk or windows sdk can give this a try, cool beans!

(In reply to comment #17)
> Created an attachment (id=1957) [details]
> unified diff between svn 1302 and the new hotness
> 
> Unified diff, hopefully this is correct.  If someone with VS2005 or VS2008 and
> either platform sdk or windows sdk can give this a try, cool beans!
> 

I haven't tried your patch, but it looks like it fixes at least two issues. IMO what you've got there is much better than what is currently in SVN. 

However, reading the diff I still see references to libcurl.lib. Since this file is not distributed as part of ioq3, I expect you to get an error trying to link unless you have obtained libcurl.lib elsewhere. Note I'm actually using VS2k3, so maybe in 2k5/2k8 its clever enough to realise that it doesn't matter if a lib cannot be found if it is not actually required.

See lines similar to:
-				AdditionalDependencies="user32.lib advapi32.lib winmm.lib wsock32.lib openal32.lib SDLmain.lib SDL.lib OpenGL32.lib libcurl.lib"
+				AdditionalDependencies="user32.lib advapi32.lib winmm.lib ws2_32.lib openal32.lib SDLmain.lib SDL.lib OpenGL32.lib libcurl.lib"

As you're defining USE_CURL_DLOPEN you do not need to link with libcurl.lib, so this should be removed from these lines.

Personally I prefer my patch to the USE_LOCAL_HEADERS constant rather than simply adding the \code\libcurl\... etc directories onto the include paths since I feel this is more correct. Unless ioq3 is intended to only use the local SDL / curl headers, I think this constant should be respected. Instead, you're making sure a "local" directory is in the search path, which means it will always use the local headers in preference to system, regardless of that constant. Compare how the jpeg includes are redirected to the local path with that constant set. However I do not particularly care - all I'm interested in is the SVN head compiles. 

(In reply to comment #14)
> For someone evaluating this bug for inclusion, I'd recommend ignoring the two
> patches that Mr. Jacques submitted as I think they were made based on the
> quake3.vcproj in SVN, not based on the quake3.vcproj I attached to this bug. 
> Unless my assumption is wrong and there's just something really hosed up?  But
> I think that's what happened--wrong quake3.vcproj was assumed to be "fixed".

Correct. Actually, I didn't know about this bug - I simply assumed that the SVN should actually build. When it didn't, I fixed the issues I hit, and then checked the bugzilla to raise a bug to report it and file the patch, and noticed you already had a bug open.

It hadn't crossed my mind that someone else had fixed it months before but the changes hadn't yet been committed. ;)

(In reply to comment #18)
> (In reply to comment #17)
> However, reading the diff I still see references to libcurl.lib. Since this

> See lines similar to:
> -                               AdditionalDependencies="user32.lib advapi32.lib
> winmm.lib wsock32.lib openal32.lib SDLmain.lib SDL.lib OpenGL32.lib
> libcurl.lib"
> +                               AdditionalDependencies="user32.lib advapi32.lib
> winmm.lib ws2_32.lib openal32.lib SDLmain.lib SDL.lib OpenGL32.lib libcurl.lib"
> As you're defining USE_CURL_DLOPEN you do not need to link with libcurl.lib, so
> this should be removed from these lines.


Looking at my project file, I do NOT use libcurl.lib, so that diff must be really jacked up.

> Personally I prefer my patch to the USE_LOCAL_HEADERS constant rather than
> simply adding the \code\libcurl\... etc directories onto the include paths
> since I feel this is more correct. Unless ioq3 is intended to only use the
> local SDL / curl headers, I think this constant should be respected. Instead,
> you're making sure a "local" directory is in the search path, which means it
> will always use the local headers in preference to system, regardless of that
> constant. Compare how the jpeg includes are redirected to the local path with
> that constant set. However I do not particularly care - all I'm interested in
> is the SVN head compiles. 

This may be intended as ioq3 seems to keep a certain set of tweaked libraries like an old version of zlib and some "fixed" version of SDL.  Also since ioq3 includes these in the source tree, that seems to reinforce that intent?  The only outlier seems to be the SDL library which on the Windows platform you have to get yourself.  Though there's a fixed sdl.dll that you need to download yourself (it'll be included in 1.36) to play ioq3, which is odd.  I'm guessing SDL is just too big and unwieldy to include in the ioq3 source tree for that fix?    I will attach the entire XML project and see if that works.  Just be aware you'll need the config.h also linked as bug 3857.

Created attachment 1965 [details]
quake3.vcproj for visual studio

Any Visual Studio wranglers, please give this a try to make sure it works.  Remember you'll need config.h in the linked bug.  I dunno, visual studio must set something zany that speex can't handle without that header but if anyone can figure out how to get it to compile without needing the config.h, go fer it!

msvc project file committed. I'd suggest to put the howtos in the wiki.

Created attachment 2003 [details]
relative SDL headers patch

I thought this appropriate to this bug as it kind of relates to MSVC project files.  The project files still need some tweaking, but can produce a binary at this stage.  I will tweak some more.  Now for the patch description...

From Jay Weisskopf on the dev mailing list:

One issue with the MSVC projects is that they don't consistently define USE_LOCAL_HEADERS. Defining it fixes errors with AL and cURL "header not found" errors, but it didn't work for SDL. When USE_LOCAL_HEADERS is defined, AL and cURL header include statements use relative paths, and SDL does not. It's not a problem using Make because the Makefile -I's the SDL include directory. I think it should be more inline with the AL and cURL method, so I created a patch doing so.

I just moved to a new apartment and I haven't set my Linux server back up yet, so the patch is untested on Linux.

Putting this down to minor and reopening.  I don't think it should block anything to be tweaked, but it should be refined a bit more.

Created attachment 2046 [details]
Patch for msvc project files

Build instructions are on the wiki and in the forums, so I might as well whack 'em from here.

This patch should get the following working:

debug
debug TA
release
release TA

Previously only release TA worked.  I recommend applying this patch ASAP as it will make the MSVC files actually useful again.

Bug should remain open, though, for evaluation of that guy's relative SDL headers patch and because the MSVC files still need:

1) dedicated server 
2) tools
3) qvm's (maybe, or maybe not worth trying)

However, the working debug configurations are immediately useful!

*** Bug 3779 has been marked as a duplicate of this bug. ***

Created attachment 2083 [details]
Re-adds SDL includes and USE_LOCAL_HEADERS

The quake3.vcproj in svn is broke for compiling ioquake3.  The only change seems to be getting rid of the SDL include directory and the USE_LOCAL_HEADERS directive.  Probably only the SDL include directory is what broke things, but I'm backing out of both changes from r1553 until someone figures out what's up with that.  Juz, maybe?  Everything else seems to work fine.  All configurations tested to work ok on both vs2005 and vs2008, win2k and winxp.

The reason for removing USE_LOCAL_HEADERS is that MSVC should not be using the local headers:

The *SDL*.a files included in the source distribution are not in a format officially recognized by MSVC (a bit of google-fu will confirm this), so they shouldn't be linked against for the MSVC build. Therefore the user should install SDL separately (adding the relevant include and lib dirs to the search path in their preferences) and use these headers, not the ones in the svn, which aren't guaranteed to be the same version.

changing asignee so bugzilla stops assaulting me.

This point is moot now, msvc2005 support might be dropped in favor of 2010

I'll have to snag me a copy of 2010 Express sometime, then.  See if it at least still will work in 2008 or if it's just 2010+.