#8766 closed patch
MSVC project files cleanup
| Reported by: | bluegr | Owned by: | bluegr |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Hello there
Currently, whenever a file gets added or removed from the scummvm project tree, and this file is needed for the Windows version to compile, we usually resort to wait for someone who has a version of Microsoft Visual Studio, so that the MS Visual C++ (MSVC) project files can be updated. This means that for every file that gets added or removed, there is a big possibility that the MSVC project files get desynced.
The current versions of MSVC that are in the trunk are: - MSVC9, Visual Studio 2008: Latest version, free version available for download from Microsoft, usually gets updated, not major differences from its predecessor (MSVC8), as the format itself seems to have matured. ScummVM compiles correctly with this one - MSVC8, Visual Studio 2005: Previous version, very similar to MSVC9, gets updated too, ScummVM compiles correctly with this one - MSVC71, Visual Studio 2003: A bit older version, quietust has supplied patches for it, project files differ from MSVC8, some tags have been changed or removed - MSVC7, Visual Studio 2002: The first IDE supporting ".net", project files for it are very similar to MSVC71, hasn't been updated in awhile, noone seems to be using it. ScummVM probably compiles though, as it's very similar to MSVC71 - MSVC6: Very old version, its project files haven't been updated for quite a while and they differ radically from the subsequent versions
Currently, I've created and uploaded 2 batch files that can be used to convert project files between MSVC9 and MSVC8. This is very useful, because if a developer has either MSVC9 or MSVC8, it's very simple to update one set of files and automatically update the other ones.
These script files can be found under /dists, as msvc9_to_msvc8.bat and msvc8_to_msvc9.bat and they're using the Windows version of the GNU rpl tool, available from:
http://gnuwin32.sourceforge.net/packages/rpl.htm
I've now created another batch file, which can convert MSVC8 files to MSVC71 and MSVC7 ones and I'm attaching it with this patch, along with a patch file for the current project files, which have been generated from this tool. The MSVC8->MSVC71->MSVC7 tool is a bit more complex, as the differences between MSVC8 and MSVC71 are more than the ones between MSVC9 and MSVC8.
The questions are: - Will the MSVC71 and MSVC7 files be kept? Should this tool be used for auto-generating them? Currently, there's only one known person using MSVC71, quietust. We could easily keep the MSVC71 and MSVC7 project files in sync with the other ones this way, but there is going to be the extra work of generating their project files, plus adding support for those old compilers themselves - Shall the MSVC6 project files be removed altogether? Noone seems to be maintaining them, it's not easy at all to create them automatically from newer MSVC project files, as they're very different, plus it's not known if ScummVM will even compile on MSVC6 any more
As mentioned, attached you'll find the script itself, plus a patch over the project files in the trunk
Ticket imported from: #1861744. Ticket imported from: patches/871.
Attachments (1)
Change History (10)
by , 17 years ago
comment:1 by , 17 years ago
My take on this: * Auto-generating as many project format as possible from a common source sounds like a very good thing * If it's "easy" for us to keep the MSVC71 and MSVC7 project files, we should do so. * Dropping MSVC6 support seems fine to me. That compiler (IIRC) had far too many problems with ScummVM anyway
However, on the long run, maybe we should consider using a tool like CMake, which can generate Makefiles, MSVC projects, XCode (Apple's dev environment) projects, Eclipse, KDevelop, CodeBlocks. Although it seems to be a bit lacking when it comes to assembler (see <http://www.cmake.org/Wiki/CMake:OpenTasks>).
comment:2 by , 17 years ago
I'm tempted to close this one
Quietust came on IRC today, saying that the latest changes to hashmap make it impossible to compile ScummVM under MSVC7.1 (Visual Studio 2003). I'm not sure if this part of the code can be fixed to work under MSVC71, like it was fixed to work for older versions of GCC.
Here's part of the IRC log (Jan 19, 2008): [21:10] <_Q> anyone here compiled latest ScummVM sources with MSVC8/9? [21:10] <_Q> (2005 or 2008) [21:11] <aquadran> yes [21:11] <_Q> hmm [21:11] <_Q> then it looks like MSVC71 is now officially incapable of building ScummVM [21:12] <_Q> Fingolfin's changes to hashmap.h last week cause errors on every file [21:12] <_Q> but only in 7.1 [21:12] <_Q> it's time to retire VS.NET 2003 [21:13] <aquadran> get free 2005/8 [21:13] <_Q> if you're curious, these are the errors: [21:13] <_Q> ../..\common\hashmap.h(128) : error C2649: 'Common::HashMap<Key,Val,HashFunc,EqualFunc>::ConstIterator' : is not a 'class' [21:13] <_Q> ../..\common\hashmap.h(122) : see reference to class template instantiation 'Common::HashMap<Key,Val,HashFunc,EqualFunc>::Iterator' being compiled [21:13] <_Q> ../..\common\hashmap.h(307) : see reference to class template instantiation 'Common::HashMap<Key,Val,HashFunc,EqualFunc>' being compiled [21:13] <_Q> thrown on every single file (...) [21:19] <[md5]> _Q: Do you get any warnings, or just the error? [21:19] <_Q> [md5]: no warnings [21:20] <_Q> 100% errors [21:21] <[md5]> hm [21:22] <[md5]> and are they all the same? [21:22] <_Q> yep [21:23] <_Q> 2003 is incapable of understanding that particular way of doing templates [21:23] <_Q> while all modern compilers handle it fine [21:23] <_Q> put simply, it's time to drop msvc71 support [21:24] <_Q> considering I'm the only person who uses it [21:25] <[md5]> hm [21:25] <[md5]> well, there were changes for some older versions of gcc [21:25] <[md5]> so perhaps we could find a way to make it compile? [21:25] <_Q> probably not worth it (...) [21:29] <[md5]> what if you completely remove line 128? [21:29] <[md5]> does it compile then? [21:38] <_Q> nope [21:38] <_Q> agi detection.cpp complains about access to protected members [21:39] <_Q> the whole point of that line being there
comment:3 by , 17 years ago
Well, I wouldn't give up that easily. It might be possible to fix building using MSVC7 easily. Of course, if _Q had just filed a bug report, instead of only complaining about this on the IRC channel, I would have known about this before backporting it to the 0.11.x branch *sigh*
comment:4 by , 17 years ago
So, is MSVC7 still having problems? Those ConstIterator problems should be fixed (although of course there might be new ones ;).
It would be nice to get this in.
comment:5 by , 17 years ago
It seems that it's not having problems, as Quietust has made some updates on the MSVC71 data files. However, I'd like some feedback on this by someone who's using MSVC71 (i.e. Visual Studio 2003) before it's submitted. Quietust is the only I know who's using this version, so I'd like some feedback from him as well. So far I have been unable to find him on IRC, and he hasn't responded to the mail I sent on -devel. I'll send him an e-mail to reply to this so that we can get his feedback
comment:6 by , 17 years ago
Finally got a chance to try this utility, and I've noted the following changes made to the project files:
1. A few project files lost ATLMinimizesCRunTimeLibraryUsage="TRUE" and nearly all of them gained DisableLanguageExtensions="FALSE" 2. scummvm.vcproj changed its IgnoreDefaultLibraryNames settings somewhat 3. zdll.lib changed to zlib.lib (fairly minor, confuses http://www.zlib.net/zlib123-dll.zip setup a bit)
After adjusting my zlib files to accomodate for #3, the new build files appear to work (though I had to make a small patch to Common/str.h to fix a bizarre compile problem I'll report elsewhere).
Go ahead and deploy it - I won't have to bother with submitting project file patches every other week.
No guarantees on the MSVC7.0 project files, though - you'll have to find somebody who still uses that.
comment:7 by , 17 years ago
Thanks for your feedback :) As for the changes you mentioned: 1. ATLMinimizesCRunTimeLibraryUsage: this is not used, so setting it to true has no effect, since ScummVM doesn't use Microsoft's ATL libraries at all. Refer to: http://en.wikipedia.org/wiki/Active_Template_Library DisableLanguageExtensions: it should be "false", otherwise VS throws a ton of warnings. It is false by default, so it doesn't matter much. Refer to: http://msdn2.microsoft.com/en-us/library/0k0w269d.aspx 2. IgnoreDefaultLibraryNames: well, those settings have always worked for me for both debug and release builds, a wrong option here stops complilation completely (and it hasn't in your case) 3. Changing zdll.lib to zlib.lib is intentional, to link the zlib library statically rather than having an extra DLL file
I'll deploy it then, thanks for your comments :)
comment:8 by , 17 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:9 by , 6 years ago
| Component: | → Port: Win32 |
|---|
MSVC auto-generation tool for version 7 and 7.1, with a generated patch for current files