Most people tend to pick the build tool they want to use, then generate a vcproj or sln from them. This is great and all when you wanna target your software to build on almost any system with GCC, cl, xcode. Whatever.
For small projects it works great. When a project is large however, programmers like to put stuff in folders and get all organized. Then your configuration changes, and you need to regenerate that vcproj. BAM! It's all flat again. Unless I'm totally wrong and Qmake or Cmake can actually generate vcproj's with filters, I haven't found that documentation.
Truth be told, I work with several proprietary VS plugins for platforms that like to store settings and configurations within the vcproj. What happens when other build tools generate vcprojs? They kinda go missing as well. I could of course go figure out what they're adding and add all these options to the vcproj generators in the bu.... NOPE.
I'm not gonna go and remake all the settings that the fantastic engineers at Microsoft and Sony have done to make it easy for programmers to actually add their platforms as targets in Visual Studio. It's good work. Let's keep it! Programmers are accustomed to being able to look at the vcproj properties in VS and double click toggle boxes and drop down lists. This is good. Let's keep most of that! I'm also not going to make my own build tool from scratch either. Not when I want to make it easy for myself to let's say use incredibuild or another distributed build plugin for VS.
So how do I configure include directories and library directories and additional libs and all these fancy things in the vcproj in an easy and quick manner?! Your probably think this is an easy task, but it's kinda tedious when you have 4 libraries, 3 platforms, with 3 configurations each. That's... a lot of places to add things to. You could use VS property sheets. But, I actually found them kind of a pain to use... cause you're still buried in a ton of different VS menus, then you have to add it to a billion project configurations. Thanks, but no thanks.
The vcproj format is pretty simple and below is a very simplified version of the format. Basically each configuration in configuration element with a name as an attribute. Then every tool is in an element with its options are stored as attribute. In the example below, the VCCLCompilerTool stores preprocessor definitions in the PreprocessorDefinitions attribute. What wtMake does is actually looks through every tool element that has the right configuration and replaces the current attribute with what you set.
<Configuration Name="Release|Win32" > <Tool PreprocessorDefinitions="DEFINITION" Name="VCCLCompilerTool"/> </Configuration>
So I wrote a little tool, that can modify almost any element in a vcproj's tool attribute to the things I need it to be. The syntax is simple and fast.
//comment :rule #vsattribute < text you want to go in there. !forceattribute ? NameAttribute < text you want to go in there.
So let's say we wanted to add freetype to the vcproj. This is the set of rules that I would need to cover everything for freetype and PC.
:pc #PreprocessorDefinitions < WF_PC32 < WIN32 < _CRT_SECURE_NO_WARNINGS #AdditionalDependencies < Ws2_32.lib xinput.lib libpad.lib !AdditionalOptions ? VCCLCompilerTool | VCCLX360CompilerTool < /MP !MinimalRebuild ? VCCLCompilerTool | VCCLX360CompilerTool < false // Freetype :freetypeinclude #AdditionalIncludeDirectories < $(ProjectDir)..\..\..\3rdparty\freetype\include :freetype360 #AdditionalLibraryDirectories < 3rdparty\freetype\objs\xbox360\vc2008 :freetypepc #AdditionalLibraryDirectories < 3rdparty\freetype\objs\win32\vc2008 :freetypeps3 #AdditionalLibraryDirectories < 3rdparty\freetype\objs\ps3\vc2008 :freetypedebug #AdditionalDependencies < freetype239MT_D.lib :freetyperelease #AdditionalDependencies < freetype239MT.lib :freetypedebugps3 #AdditionalDependencies < freetype239MT_D.a :freetypereleaseps3 #AdditionalDependencies < freetype239MT.a
So now that's fine and dandy. How do we use the rules? Well then, now we have a project template. The format is something like this.
$templatename #all < rule #Configuration|Platform < rule
#all is a special tag so that it's added to all configuration.
Here is an example of just the pc portion of a game project template.
$mygame #all < bulletincludes < raknetcompiler < wfEngineSource #Debug|Win32 < debug < pc < directxCompiler < directxdebug < freetypepc < freetypedebug < physxpcCompiler < physxpc < bulletpclibs < force #Release|Win32 < release < pc < directxCompiler < directxrelease < freetypepc < freetyperelease < physxpcCompiler < physxpc < bulletpclibs < force #Final|Win32 < final < pc < directxCompiler < directxrelease < freetypepc < freetyperelease < physxpcCompiler < physxpc < bulletpclibs < force
So how do you actually use the tool? Simple.
wtmake example.vcproj -t templatename
if you'd like to use it with the example above :
wtmake mygame.vcproj -t mygame
GOTCHAS!
The tool will completely replace all text in that attribute! So if you have a preexisting project you'd like to modify with it, make sure you have a backup in case you don't get all the configurations the first time!
The tool is modifies only elements that exist, if it doesn't find one. It doesn't add it. I wrote it this way to simplify the actual tool rule syntax. So you don't have to worry about the 100's of other Tool elements.
If you need to force an attribute, like for AdditionalOptions to add the all important /MP switch to cl. You can do that by using a ! for a forceattribute . It will create it if the element has an attribute called "name" that matches. This is the method I used to add /MP to only the VCCLCompiler tool and not to VCCustomBuildTool,VCMIDLTool and all the other ones.
If you are interested, you can download this tool from here. There is an example PC project with a bunch of libraries already preconfigured in the file called wtMakeConfig.
If you want source, please feel free to ask me. I may release it eventually after I clean it up of some dependencies of other libs. Released under zlib.
