Abstract:
A method and apparatus in a data processing system for processing errors during building of a program. A set of tools needed to build the program is identified. Each tool within the set of tools is called. Responsive to a tool within the set of tools generating output, a determination is then made as to whether an error is present in an output generated by the tool. Responsive to determining a presence of the error, a notification is automatically generated.

Description:
BACKGROUND OF THE INVENTION 
     1. Technical Field 
     The present invention relates generally to an improved data processing system and in particular to a method and apparatus for building a program. Still more particularly, the present invention provides a method and apparatus for identifying errors during compiling and linking of a program. 
     2. Description of Related Art 
     In creating programs and applications, developers will generate code in a high level form and use translators to translate the code to create executable program code, which is also referred to as object code. A commonly used translator is a compiler, which translates high level source code into machine language object code. In creating programs and applications, numerous modules may be created, requiring compiling by a compiler. Additionally, data files often are created for use with the modules. A linker is a tool used to link the compiled modules and data files to create an executable program. Other tools also are used in creating programs. These tools include, for example, SED, AWK, COPY, and MSGBIND. The SED utility is a “stream editor”, a program that reads a stream of data, makes changes to it, and passes the modified data on. The basic function of AWK is to search files for lines (or other units of text) that contain certain patterns. When a line matches one of the patterns, AWK performs specified actions on that line. MSGBIND is a utility program to bind a binary message file to an executable program. There is usually a separate binary message file for each supported national language. The creation of an executable program from modules and data files is also referred to as a software build. 
     A tool such as a make utility is used to automatically determine which build steps to execute. It invokes the appropriate build compilers, linkers, and other tools, and directs the output to a log file. GNU make is an example of a make utility. More information on GNU make may be found in GNU make Version 3.77, which is published by the Free Software Foundation 59 Temple Place, Suite 330, Boston, Mass. 02111-1307, ISBN 1-882114-80-9. Determining the success of a software build by a make utility is presently identified by checking the build output in the log file. This log file contains the output from each tool called by the make utility. Currently, this log file is checked for errors to decide the pass or fail status of the software build when the make utility completes execution. A significant amount of time may pass between when an error occurs and when the error is detected. For example, compile time for a program like an operating system may take hours depending on the size and complexity of the program, the speed of the compiler, and the performance of the hardware. Compile errors may happen at the beginning of the process, but the software build will continue to create unaffected parts and log these results to the log file. The analysis currently is postponed until all processes are complete. 
     Therefore, it would be advantageous to have an improved method and apparatus for quickly identifying errors occurring during a software build. 
     SUMMARY OF THE INVENTION 
     The present invention provides a method and apparatus in a data processing system for processing errors during building of a program. A set of tools needed to build the program is identified. Each tool within the set of tools is called. Responsive to a tool within the set of tools generating output, a determination is then made as to whether an error is present in an output generated by the tool. Responsive to determining a presence of the error, a notification is automatically generated. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: 
     FIG. 1 is a pictorial representation depicting a data processing system in which the present invention may be implemented in accordance with a preferred embodiment of the present invention; 
     FIG. 2 is a block diagram illustrating a data processing system in which the present invention may be implemented; 
     FIG. 3 is a diagram of a software build system depicted in accordance with a preferred embodiment of the present invention; 
     FIG. 4 is a flowchart of a process used in a wrapper depicted in accordance with a preferred embodiment of the present invention; and 
     FIG. 5 is a flowchart of a process used by a output processor depicted in accordance with a preferred embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     With reference now to the figures and in particular with reference to FIG. 1, a pictorial representation of a data processing system in which the present invention may be implemented is depicted in accordance with a preferred embodiment of the present invention. A personal computer  100  is depicted which includes a system unit  110 , a video display terminal  102 , a keyboard  104 , storage devices  108 , which may include floppy drives and other types of permanent and removable storage media, and mouse  106 . Additional input devices may be included with personal computer  100 . Personal computer  100  can be implemented using any suitable computer, such as an IBM Aptiva™ computer, a product of International Business Machines Corporation, located in Armonk, N.Y. Although the depicted representation shows a personal computer, other embodiments of the present invention may be implemented in other types of data processing systems, such as network computers, Web based television set top boxes, Internet appliances, etc. Computer  100  also preferably includes a graphical user interface that may be implemented by means of systems software residing in computer readable media in operation within computer  100 . 
     With reference now to FIG. 2, a block diagram illustrating a data processing system in which the present invention may be implemented. Data processing system  200  is an example of a computer, such as computer  100  in FIG. 1, in which code or instructions implementing the processes of the present invention may be located. Data processing system  200  employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor  202  and main memory  204  are connected to PCI local bus  206  through PCI bridge  208 . PCI bridge  208  also may include an integrated memory controller and cache memory for processor  202 . Additional connections to PCI local bus  206  may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter  210 , small computer system interface SCSI host bus adapter  212 , and expansion bus interface  214  are connected to PCI local bus  206  by direct component connection. In contrast, audio adapter  216 , graphics adapter  218 , and audio/video adapter  219  are connected to PCI local bus  206  by add-in boards inserted into expansion slots. Expansion bus interface  214  provides a connection for a keyboard and mouse adapter  220 , modem  222 , and additional memory  224 . SCSI host bus adapter  212  provides a connection for hard disk drive  226 , tape drive  228 , and CD-ROM drive  230 . Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors. 
     An operating system runs on processor  202  and is used to coordinate and provide control of various components within data processing system  200  in FIG.  2 . The operating system may be a commercially available operating system such as OS/2, which is available from International Business Machines Corporation. “OS/2” is a trademark of International Business Machines Corporation. An object oriented programming system such as Java may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system  200 . “Java” is a trademark of Sun Microsystems, Inc. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on storage devices, such as hard disk drive  226 , and may be loaded into main memory  204  for execution by processor  202 . 
     Those of ordinary skill in the art will appreciate that the hardware in FIG. 2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash ROM (or equivalent nonvolatile memory) or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIG.  2 . Also, the processes of the present invention may be applied to a multiprocessor data processing system. 
     For example, data processing system  200 , if optionally configured as a network computer, may not include SCSI host bus adapter  212 , hard disk drive  226 , tape drive  228 , and CD-ROM  230 , as noted by dotted line  232  in FIG. 2 denoting optional inclusion. In that case, the computer, to be properly called a client computer, must include some type of network communication interface, such as LAN adapter  210 , modem  222 , or the like. As another example, data processing system  200  may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system  200  comprises some type of network communication interface. 
     The depicted example in FIG.  2  and above-described examples are not meant to imply architectural limitations. For example, data processing system  200  also may be a notebook computer or hand held computer. 
     The present invention provides a method, apparatus, and computer implemented instructions for quickly identifying errors during a software build. The mechanism of the present invention intercepts the output from individual tools called by a software build management utility, such as a make utility. The mechanism of the present invention involves providing a wrapper for a tool to intercept calls and direct the calls for analysis as the tool generates output. The analysis may be made by the tool or by a separate analysis unit. Upon detection of an error, various notifications may be made such as, an audible alert, a visual alert or sending a notification to a programmer via a pager. Additionally, notifications may be made when certain selected check points or milestones are reached during the software build process, such as the completion of building major components. 
     With reference now to FIG. 3, a diagram of a software build system is depicted in accordance with a preferred embodiment of the present invention. Software build system  300  includes a make utility  302 . Software build system  300  also includes compile tool  304 , link tool  306 , bind tool  308 , copy tool  310 , and SED tool  312 . In the depicted examples, wrappers  314 - 322  are associated with the tools. Make utility  302  will read a make file to determine which build steps are to be performed based on the make file. A make file describes dependencies and relations between different files and tells make utility  302  how to compile and link a program. More information on make files may be found in GNU make Version 3.77. 
     Based on the make file, a tool will be called by make utility  302 . For example, compile tool  304  may be called by make utility  302 . Wrapper  314  will take over the call made by make utility  302  to compile tool  304 . This interception of a call is accomplished by placing the wrapper ahead of the tool in the calling hierarchy make utility  302 . This may be accomplished in a number of ways. For example, the wrapper for a tool may be placed first in a call path or have a higher order file extension. 
     The output from compile tool  304  is directed to output processor  324 . In the depicted example, output processor  324  will check for errors in the output received from a wrapper and generate an alert in response to detecting an error or a build break, which occurs from an error. In the depicted examples, the build analysis occurs immediately whenever output is received from a tool. Additionally, the build status may be updated. The output echoed or sent to output log file  326 . This output log contains the output from each tool called by make utility  302 . This log provides a chronology of events that occur during a software build. A similar process is used for other tools in software build system  300 . 
     With reference now to FIG. 4, a flowchart of a process used in a wrapper is depicted in accordance with a preferred embodiment of the present invention. The processes illustrated in FIG. 4 may be implemented in a wrapper, such as wrapper  314 , associated with a tool, such as compile tool  304  in FIG.  3 . 
     The process begins by receiving a call to the tool associated with the wrapper (step  400 ). A call is made to the tool associated to the wrapper (step  402 ). The original arguments for the received call are passed with the call (step  404 ). The output is sent to a temporary file (step  406 ), and an output processor, such as output processor  324  in FIG. 3, is invoked (step  408 ) with the process terminating thereafter. 
     With reference now to FIG. 5, a flowchart of a process used by a output processor is depicted in accordance with a preferred embodiment of the present invention. These processes may be implemented in an output processor, such as output processor  324  in FIG.  3 . The process begins by receiving output from a tool (step  500 ). Thereafter, the output is checked for errors (step  502 ). A determination is made as to whether an error is present (step  504 ). If an error is not present the status is updated (step  506 ), and the output is sent to a log file for later analysis (step  508 ) with the process terminating thereafter. 
     With reference again to step  504 , if an error is present an alert is generated (step  510 ) with the process then proceeding to step  506  as described above. This alert may take various forms depending on the implementation. For example, the alert may be in the form of an audible alert at the workstation on which the processes are executing. The alert may be sent to another workstation at which a programmer is located. This alert also may take the form of an email message or a message sent via a pager. Additionally, alerts also may be generated for reaching a check point or milestone in the bill process. 
     Thus, the present invention provides an ability to perform more immediate detection of errors as they happen during a build process. This advantage is provided by using a wrapper mechanism to intercept calls to tools and routing the output from the tools to an error analysis program, the present invention allows output from a tool to be analyzed individually, rather than waiting for the build process to end. Further, the analysis is directed towards the output of a specific unique step and does not require a re-examination of the entire build log. The depicted example allows for implementation in an established build process without reworking or changing make files. 
     It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links. 
     The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. For example, a modification may be made to the make utility program to redirect tools to a common wrapper in which this wrapper will invoke the appropriate tool and then invoke the output processor. This allows a single wrapper to be used instead of one for each tool. The modification is made to the make utility program without requiring changes to the make files. Alternatively, the make files may be modified to change the tool calls to the common wrapper. In this case, no change needs to be made to make utility program. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.