How are MS Visual C++ environments generally setup?

Question

I come from a Java background, and the shop where I currently work refuses to use anything other than MS VC++ to build their legacy project. They don't appear to use any standards for setting up their build environment other than just building it using VS2005 and clicking the compile button.

I was wondering if there was anything closer to what Java had for instance:

• A build tool like ANT or Maven
• A directory structure that makes sense containing
  • src - Place for all my source files .c/.cpp/.h
  • lib - A place for any libraries that might be used in the project (.dll, .lib)
  • dist - A place for the output executable/distribution of the project
  • resources - A place for any images/sounds/text files that might be included in the project.
  • build.xml - Some sort of a build file (my guess would be something like ./configure or MAKEFILE)

Or am I asking too much from a C++ build environment? Is it just always as chaotic as the people in my shop make it out to be? I really have a hard time believing that considering the success of so many C++ projects on the internet.

Answer 1

The standardized stuff:

• The build tool: Visual Studio (doesn't need an extra product)
• Build file: *.sln / *.vcproj (*.vbproj for Visual Basic, etc)
• Directory structure: "Debug" and "Release" directories for the output binaries.

The rest isn't so much "chaotic" as "doesn't really matter". "Chaotic" suggests that it changes all the time, but in reality you just pick one for a project and stick with it. Companies may have internal standards across projects. It just doesn't matter enough to bother standardizing across companies. C++ is a complex language anyway; anyone with sufficient IQ to read C++ can deal with reasonable variation. The difference between \lib\ and \Library\ won't stop them.

Answer 2

MSVC does not impose any directory structure on you. There are some defaults, as mentioned above for the Debug and Release directories, for example, but even these can be overridden on a per-project basis. Use whatever directory structure makes sense to you.

Visual Studio does provide command line support if you don't want to use the IDE. See This MSDN Article for more information.

Answer 3

You can setup a proper build environment using Visual Studio (and for solutions with more than one project, you should), and there are a number of environment variables to use in the project configuration to set so that output files and intermediate files go to different folders than those defined by default.

In our large VS solution, we use e.g. obj/$(ProjectName)/$(ConfigurationName) as intermediate directory and bin/$(ConfigurationName) as output directory in all sub-projects.

All these things must be enforced by the user, and it seems that no single recommendation/best practice has evolved.

Answer 4

It sounds like you have good intentions - coming form a non MSVC world I can see your points.

If I were in y our shoes I would definitely make a command line/automated build/build server.

You can use MSBuild for this - and hudson has a plugin for this. I usually have a "Build" directory near the root of the projects that contains scripts/etc that will call the appropriate MSBuild/.sln files.

The "makefiles" for Visual Studio are .sln and .vcproj files. You can call those with msbuild from the command line. You can also export a makefile (I think that is still an option) from within the IDE that you can run. I don;t recommend going that route though other than trying it out and seeing what is output - since that is what you are familiar with.

Both the vcproj and sln files are human readable - go through them - it will give you some useful information.

I would also agree that having a distributon directory is good - for building an installer/etc after the build. Copy all the needed binaries there - either in postbuild steps or in another script/etc.

Let us know what you end up doing.

I have one other piece of advice: UPGRADE to VC/Dev studio 2008 or 2010. ASAP