Rock Hymas

It’s important that you have a single build script to build your product - every configuration of your product. Having a separate script for debug vs release, or x86 vs x64 architecture, is only going to cause problems. If the actual built files need to be different for different deployment target, then these targets also become build configurations, such as hosted vs installed. And the build script need to be able to build each of these configurations.

The easiest way to do this is to have the build script take command line parameters that specify which configurations to build (or to build all of them). The command line parameters should be short, or have short versions, to make it easier to run the script frequently.

Rather than specify that the script should build one configuration or another, it should be allowed to build multiple configurations. This requires that each configuration build to a different location. So you may have a build directory next to or within your source directory, that has a subdirectory for each configuration built. The simplest example of this is Visual Studio’s bin\Debug and bin\Release directories for it’s default projects.

Obviously, you shouldn’t need to enter command line parameters. The defaults should be the configuration(s) that developers will use most often. It may be helpful to make it easy for developers to easily configure their defaults in a settings file, if different developers have different needs.