Modern software is typically created with a great deal of computer automated assistance. Such assistance is commercially available in a variety of software, generally referred to as integrated development environments (IDEs). For example, MICROSOFT'S VISUAL STUDIO®, BORLAND'S C++ BUILDER®, METROWERK'S CODE WARRIOR®, and IBM'S WEBSPHERE STUDIO® are all products presently available to assist in software creation. Such products provide a range of useful functions, such as coordinating communications between multiple developers working together on large projects, assisting in the actual writing of source code, assisting in specifying how a source code file will be compiled, and providing compilers and other processes that convert a source code files and the like into executable files.
The process of developing software using an IDE is depicted in FIG. 1a. First, the software can be designed using a design tool 100. The design tool 100 will typically provide a wide range of design functions for generating any number of files 110a-110h. Files 110a-110h may be files of a variety of types. Some may be files containing source code, while others are files that specify some other properties of the software under development. When the files 110a-110h for a software application are ready, they may be passed to what is known as a build process 120. Many IDEs have built-in build processes 120. While some IDE products may bifurcate the creation of the files 110a-110h and the build-process 120, others provide software design and build as options through a single user interface.
The build process 120 may comprise any number of sub-processes 121-124. One such sub-process is typically a compiler 121. A compiler 121 is software that provides a function of reading source code and generating binary files, which may be computer-executable, or near-computer-executable files. Compilers may provide this function in any number of different ways, leading ultimately to differences in the computer executable files that are generated. Moreover, compilers 121 may provide a plurality of options that allow a user to specify properties of the output executable files 145, 146, 147. For example, a user may wish to compile executable files that are as small in disk size as possible. Other users may not care about disk size, and may care instead about performance. Source code and other files can also be compiled to optimize performance. A host of other options allowing users to control the properties of executable files are available through modern compilers. These properties may be stored in one or more files 131-134 available to the build process 120. Thus, when the time comes to convert the original files 110a-110h into executable files 145, 146, 147, the build process has access to the build property files 131-134 governing how the build is to be conducted.
Similarly, the other sub-processes 122-124 may provide options regarding how the original files 110a-110h are converted into executable files 145, 146, 147. A host of such sub-processes are available through modern IDEs, and many offer multiple build options. The result is that a build properties file, e.g. 131 may provide a large number of build option selections.
A solo developer may run an IDE on a personal computer, and perform all of the above steps on a single machine. In another scenario, a team of developers may work together on an application. In this scenario, the network of collaborating developers may look similar to FIG. 1b. 
As suggested by the FIG. 1b, a central server 150 may be used to coordinate the efforts of a number of developers using client devices 149, 155, 160, 165. The developers may each have a variety of responsibilities in implementing aspects of a large software application. It is important that the various aspects of software work together properly. It is also preferable to ensure centralized control over a software application, so that developers cannot inadvertently alter the application without approval through the proper channels. Without such centralized control, the development environment can quickly become one in which there are many copies of an application, each with differing features, and it becomes impossible to move forward with production.
Thus the central server 150 is frequently called a “Source Code Control” (SCC) engine 150. The means by which most SCC engines 150 coordinate development is through sync and check-in procedures. When a developer first retrieves existing software under development from the SCC engine 150, it is called a sync 151. A sync 151 creates a copy of the application on the developer's client computer 149. This provides the developer with an official copy of the application under development, so he or she can work with the existing features of the application. A check-in 152 occurs when the developer returns his or her modifications to the SCC engine 150; and thereby updates the official version of the application under development. A set of modifications may be subject to review prior to check-in 152. If the modifications made by a developer conflict with other modifications, then the modifications may have to be scrapped.
In both the scenario of a solo developer and that of the team of collaborating developers, the proliferation of files can be a problem. Referring back to FIG. 1a, consider the problems that can occur if multiple files 131, 132, 133 are kept for the purpose of using a different set of build options in various builds of executable files 145, 146, 147. First, where possibly hundreds of options are specified, a problem arises as to which file contains which option selections. A set of options may have been determined, but those working on the software may not remember all of the considerations that went into the choice. If the file containing the “official” build selections, e.g. 131, is not properly tracked, it could be confused with other build options files 132, 133. This could require redundant consideration of issues already addressed, at considerable expense.
Second, a problem arises when multiple builds of software applications, and portions of applications, are made using multiple build options files 131, 132, 133. The use of differing build options is often desired for the purpose of testing the software being developed in various configurations. However, a build options file 131 used for a particular executable file, e.g. 145, may not be remembered. Thus, if a bug is found in a particular executable file 145, but the build options are not known, the bug may be more difficult or impossible to investigate. Likewise, if a particular build 145 solves a number of problems, but the build options file 131 that was used is not known, then it may be impossible to repeat or examine the reason for the new behavior.
In light of the above described deficiencies in the art, there is a need in the industry to provide systems and methods to better manage build options files in of software development.