See BuildRobot
See ConfigMapDoc
A "Configuration" is just a name that the build master invents for his or her own purposes. The number of configurations is unlimited. There is no "standard" set of names. Typical configuration names include Debug and Release.
Configuration names eventually correspond to the actual projects that are built, whether they are makefiles or Visual Studio projects or scripts or whatever. This is where configuration mapping comes in.
The ConfigMapDoc was made initially for VC++ 6.0 projects. We needed a way to convert a generic configuration name like "Debug" to real configuration names as they appeared in project (.DSP) files, like "Unicode Debug." The problem is worse for Release builds which have lots of variants like "MinSize" and "MinDependency."
For the most part, configuration mapping isn't needed for Visual Studio .NET (sln) files because configuration mapping is built in. For example, when you build a Visual Studio .NET project (SLN file), if you don't provide mappings, the configuration names specified in the BuildOptionsDoc are sent to devenv.exe. It's then up to Visual Studio to decide what to do with the configuration name. For example, "Debug" might mean to build "webservice.csproj" using the Debug configuration.
Not every configuration name has to map to every project that will be built. Some projects are ignored for certain configurations. This is controlled via the <Configuration> elements in the BuildDoc.
We also found configuration mapping to be useful for makefiles. Makefile targets are different for "debug" and "release" configurations. The ConfigMapDoc can contain the makefile targets rather than putting this same information into the BuildDoc document. Without a config map, the BuildDoc becomes very repetitive; for example:
<Build>foo.mak <Nmake>1</Nmake> <Configuration>debug</Configuration> <Targets>debug</Targets> </Build>
<Build>foo.mak <Nmake>1</Nmake> <Configuration>release</Configuration> <Targets>release</Targets> </Build>