Using Makefile instead of Solution/Project files under Visual Studio (2005)

Question

Does anyone have experience using makefiles for Visual Studio C++ builds (under VS 2005) as opposed to using the project/solution setup. For us, the way that the project/soluti

Answer 1

I've found some benefits to makefiles with large projects, mainly related to unifying the location of the project settings. It's somewhat easier to manage the list of source files, include paths, preprocessor defines and so on, if they're all in a makefile or other build config file. With multiple configurations, adding an include path means you need to make sure you update every config manually through Visual Studio's fiddly project properties, which can get pretty tedious as a project grows in size.

Projects which use a lot of custom build tools can be easier to manage too, such as if you need to compile pixel / vertex shaders, or code in other languages without native VS support.

You'll still need to have various different project configurations however, since you'll need to differentiate the invocation of the build tool for each config (e.g. passing in different command line options to make).

Immediate downsides that spring to mind:

• Slower builds: VS isn't particularly quick at invoking external tools, or even working out whether it needs to build a project in the first place.
• Awkward inter-project dependencies: It's fiddly to set up so that a dependee causes the base project to build, and fiddlier to make sure that they get built in the right order. I've had some success getting SCons to do this, but it's always a challenge to get working well.
• Loss of some useful IDE features: Edit & Continue being the main one!

In short, you'll spend less time managing your project configurations, but more time coaxing Visual Studio to work properly with it.

Answer 2

We have a similar set up as the one you are describing. We support at least 3 different platforms, so the we found that using CMake to mange the different Visual Studio solutions. Set up can be a bit painful, but it pretty much boils down to reading the docs and a couple of tutorials. You should be able to do virtually everything you can do by going to the properties of the projects and the solution. Not sure if you can have all three platforms builds living together in the same solution, but you can use CruiseControl to take care of your builds, and running your testing scripts as often as needed.

Answer 3

You can use nant to build the projects individually thus replacing the solution and have 1 coding solution and no build solutions.

1 thing to keep in mind, is that the solution and csproj files from vs 2005 and up are msbuild scripts. So if you get acquainted with msbuild you might be able to wield the existing files, to make vs easier, and to make your deployment easier.

Answer 4

Visual studio is being built on top of the MSBuild configurations files. You can consider *proj and *sln files as makefiles. They allow you to fully customize build process.

Answer 5

While it's technically possible, it's not a very friendly solution within Visual Studio. It will be fighting you the entire time.

I recommend you take a look at NAnt. It's a very robust build system where you can do basically anything you need to.

Our NAnt script does this on every build:

1. Migrate the database to the latest version
2. Generate C# entities off of the database
3. Compile every project in our "master" solution
4. Run all unit tests
5. Run all integration tests

Additionally, our build server leverages this and adds 1 more task, which is generating Sandcastle documentation.

If you don't like XML, you might also take a look at Rake (ruby), Bake/BooBuildSystem (Boo), or Psake (PowerShell)