Software applications execute on computing devices to perform a variety of functions related to processing and presenting information to users. A large application is typically made up of one or more source code modules, each written in a high-level programming language designed to facilitate human understanding of the steps involved in each module. Example high-level programming languages include FORTRAN, Microsoft Visual Basic, C, C++, and Java®. Statements in such languages are combined to write each module. One or more source code modules are stored together in a source code file. The statements are converted to instructions for a processor on a computing device, which instructions are sometimes called machine instructions, by a particular process, such as a compiler. A compiler generates machine instructions based on several statements or an entire module. The machine instructions are peculiar to particular families of processors.
The machine instructions derived from a source code module constitute an object code module. One or more object code modules are stored together in an object code file. Object code modules use relative addresses to refer to locations in memory. An executable code is generated from object code by linking together the object code and converting relative addresses to absolute addresses.
After the source code modules that make up the software application are written in a programming language, the application is built from the source code files. Building involves retrieving the files containing the source code modules and compiling or interpreting them, depending on the language of the source code, to produce object code files. In some circumstances other files that contain data used by the modules are also retrieved. In some circumstances, building also involves storing one or more object files together with any data files needed in one or more packages. In some circumstances, the modules are linked together and stored as an executable in one of the packages. Some systems use dynamic linking, which links object code modules as needed during the course of the processing. In systems using dynamic linking, the executable is not generated during the build process or stored in one of the packages. The packages are then deployed in one or more directories on a computing device, or on one or more computing devices on a network, to be accessed by users of the application.
For example, in the Java language each source code module is a class that defines attributes and methods for objects formed from the class. The Java class is compiled into bytecode that is executed by a Java virtual machine (JVM) process running on a processor. Under some circumstances, a Java application is formed by packaging bytecode of all the Java classes for the application in a Java archive (“jar”) file. The jar file may then be downloaded from one computing device on a network to a second computing device on the network. The application may then be executed on the second computing device.
Building and deploying a large application is a tedious task. Dozens of modules in thousands of files spread over dozens of directories may be involved. Some modules are used only in testing and should be included in debug versions but not in release versions of the application. Some modules change with different versions of the application. Some modules are appropriate for interactions with a web server and others for interaction using other network protocols or no network at all. Thus the modules used in a build depend to some extent on the way the application is deployed.
Several tools have been developed to handle tasks involved in building an application. For example, “make” tools are available on several computer devices running the UNIX operating system and derivatives thereof, such as LINUX. Similar make tools are available for other operating systems. A make tool receives, as input, a make file that is manually prepared by a build engineer and includes names and locations of modules and data files, and names and locations of packages, as well as names and locations of compilers, interpreters and linkers. The make tool processes the make file and generates a set of operating system commands to retrieve and compile the modules listed in the input and to package object code files or executable files with data files. However, a disadvantage is that such tools may be configured to operate only with a specific operating environment configuration.
Another disadvantage is that the build data is retrieved from two locations: the source files (e.g., as directed by import or include statements) and the makefiles (e.g., including the jar file that such files belong to). This makes the build data complicated and hard to handle. Still another disadvantage is that the makefiles, operation of the make tool, and overall supervision of the build process is normally carried out by a release engineer or build engineer, whereas the best source of knowledge about the contents of the source code is normally a different individual, such as a development engineer. Thus, there is no central point of comprehensive knowledge about both the source code and the build process.
Recently, a tool called “Ant” has been introduced that allows the build engineer to specify input for the build tool in an extensible markup language (XML) file. The Ant tool processes the XML file and executes necessary commands in the same general manner as Make. “Ant” is written in Java, and therefore runs on a larger variety of operating systems; it is also more expressive than Make, and is extendible. Descriptions of the Ant tool at the time of this writing can be viewed from file index.html on the ant directory on the worldwide web (www) at domain jakarta.apache.org.
In this description, the term “build” tool is used to refer to any tool, including make tools and Ant, which packages compiled code to form an application.
A problem arises in building complex applications that are created by a team of engineers or developers, because the information used for the build tool does not reside in the knowledge of a single person or working group. The choice of package names and the use of individual modules in different deployments of the application are best known to the application developer or development group. However, information about the deployment computer devices and installed tools is best known by a build engineer or build group. For example, the choice of the number and location of packages depends on the components, architecture and operating systems of the deployment computing devices and network. The choice of compilers, interpreters, and linking processes depend on the software tools already installed on the deployment computing devices and network. The expressions for listing modules, files and tools depend on the scripting language or XML input used in the build tool.
One past approach is for the developer to provide the build engineer with source code. The build engineer employs a build tool to construct the packages. If the build engineer does not include all the modules needed, an error occurs during the build or upon execution of the resulting application. Upon occurrence of an error, the build engineer communicates with the developer to formulate some corrective action. The process is repeated until an application is produced without errors.
However, this approach has numerous disadvantages. It is tedious to reiterate the process and test for errors. Even if no errors are found, the application may include extraneous modules that did not cause an error. For example, the packages may include debug routines that are not used in a release version. As another example, the package may include obsolete modules that cause a known fault in some circumstances not apparent to the build engineer and not expressed during routine testing. Furthermore, after several months or years of evolution for the application, the original developer may no longer be employed by the company that provides the application. Thus the original developer may be inaccessible to the build engineer.
Based on the foregoing, there is a clear need for techniques that automatically provide, for the build process, any build information known to the application developer.