Efficient generation of executable file from program files when some of the ...

1 EFFICIENT GENERATION OF EXECUTABLE FILE FROM PROGRAM FILES WHEN SOME OF THE PROGRAM FILES EXPRESSLY INCORPORATE OTHER PROGRAM FILES

RELATED APPLICATIONS

The present application is related to and claims priority from the co-pending India Patent Application entitled, “Eflicient Generation of Executable File From Program Files When Some of the Program Files Expressly Incorporate Other Program Files”, Serial Number: 548/ CHE/ 2006, Filed: Mar. 27, 2006, naming the same inventors as in the subject patent application.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to softWare, and more specifically to a method and apparatus to generate an executable file from program files When some of the program files expressly incorporate other program files.

2. Related Art

A program file is typically represented as text containing a list of instructions in a programming language. Large program files may be split into a number of smaller program files for separating functionality, providing modularity and/ or for ease of usage, as is Well understood in the relevant arts.

In general, instructions are provided by the programming language using Which program files can be expressly incorporated into one another-thereby effectively designed for operation as one large program file. For convenience, the file incorporating another file is referred to as an “incorporating file” and the file being incorporated is referred to as an “incorporated file”.

An example of such a programming language is C programming language Where large program files can be split into header and source files. The C programming language provides a construct “#include <filename>” by Which one header or source file can expressly incorporate another header or source file. Typically, source files ending With extension “.c” incorporate header files ending With extension “.h”.

Program files need to be converted into an executable file before they can be executed by the underlying hardWare. The executable file generally contains instructions (typically in binary form) suitable for execution by the processors contained in the hardWare.

The process of generating an executable file from program files typically consists of converting (or compiling) each program file into a compiled file using a compiler of the programming language and then building the executable file from the compiled files. Building generally entails linking the compiled filed into an executable file noted above.

Typically, an executable file is generated from a large number of program files. As such, a change made in one of the program files may necessitate the recompilation of all the program files, Which is not desirable. Various approaches have been proposed for increasing the efliciency of generating an executable file from program files.

In one prior approach, a program file is recompiled only When the modification date of a program file (as maintained by the underlying operating system) is more recent than the modification date of its corresponding compiled file. Such an approach is used in utilities such as ‘make’ and ‘gmake’ Well knoWn in Unix type environments and ‘nmake’ Well knoWn in WindoWs type environments.

2

One disadvantage With such an approach is that consideration of modification date alone may not lead to efficient generation of accurate executable file since incorporating files need to be recompiled if the incorporated files are modified. Various aspects of the present invention overcome such deficiencies as described in sections beloW.

What is therefore needed is an approach, Which enables the eflicient generation of an executable file from program files While addressing one or more problems/requirements described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention Will be described With reference to the accompanying draWings briefly described beloW.

FIG. 1 is a block diagram illustrating the details of a digital processing system in Which various aspects of the present invention are operative by execution of appropriate softWare instructions.

FIG. 2 is a floWchart illustrating the manner in Which an executable file can be generated from program files Wherein some of the program files expressly incorporate other program files according to an aspect of the present invention.

FIG. 3A depicts the contents of some program files used to generate an executable file in an example scenario according to some aspects of the present invention.

FIG. 3B depicts a hierarchy representation of the dependency information generated by parsing the program files of FIG. 3A.

FIG. 3C depicts the contents of a file stored in secondary storage containing the dependency information generated from the program files of FIG. 3A.

FIG. 4A depicts the contents of some program files used to generate an executable file, Which conditionally incorporate other files in an example scenario.

FIG. 4B depicts a hierarchy based on the dependency information generated from the program files of FIG. 4A.

FIG. 4C depicts the contents of a file stored in secondary storage containing the conditional dependency information generated from the program files of FIG. 4A according to an example convention/format.

FIG. 5 is a block diagram illustrating an example implementation in Which several aspects of the present invention are implemented.

In the draWings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The draWing in Which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

1. OvervieW

An aspect of the present invention generates an executable file accurately from program files by using dependency information betWeen incorporated files and incorporating files. The dependency information is generated by parsing the program files and is stored in secondary storage. On receiving an indication that a program file has been modified, the dependency information is retrieved from secondary storage and is used to identify for recompilation all the incorporating files that incorporate (directly or indirectly) the modified program file. By recompiling all the incorporating files along With the modified program file, the executable file can be generated accurately.

3

Another aspect of the present invention generates an executable file accurately when the program files are conditionally incorporated. Data representing each condition is stored associated with each file in which the condition is present. In an embodiment, the result of evaluation of a condition depends on whether a flag (part of the condition) is defined or not, and data representing the specific flags which are defined is also received. On receiving an indication that a program file has been modified, the conditions associated with the program files are evaluated (based on the flag information in the noted embodiment), and used to identify the incorporating files which have to be recompiled for accurately generating the executable file.

Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.

2. Digital Processing System

FIG. 1 is a block diagram illustrating the details of digital processing system 100 in which various aspects of the present invention are operative by execution of appropriate software instructions. Digital processing system 100 may contain one or more processors such as central processing unit (CPU) 110, random access memory (RAM) 120, secondary memory 130, graphics controller 160, display unit 170, network interface 180, and input interface 190. All the components except display unit 170 may communicate with each other over communication path 150, which may contain several buses as is well known in the relevant arts. The components of FIG. 1 are described below in further detail.

CPU 110 may execute instructions stored in RAM 120 to provide several features of the present invention described in the present application. CPU 110 may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU 110 may contain only a single general purpose-processing unit. RAM 120 may receive instructions from secondary memory 130 using communication path 150.

Graphics controller 160 generates display signals (e.g., in RGB format) to display unit 170 based on data/instructions received from CPU 110. Display unit 170 contains a display screen to display the images defined by the display signals. Display unit 170 may be used to display the dependency information (described below) stored in secondary memory 130. Input interface 190 may correspond to a key-board and/ or mouse. Network interface 180 provides connectivity to a network and may be used to communicate with other external systems.

Secondary memory 130 may contain hard drive 135; flash memory 136 and removable storage drive 137. Some or all of the data and instructions may be provided on removable storage unit 140, and the data and instructions may be read and provided by removable storage drive 137 to CPU 110. Secondary memory 130 may be used to store the dependency information generated from the program files (also potentially stored in secondary memory 130). Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 137.

Removable storage unit 140 may be implemented using medium and storage format compatible with removable storage drive 137 such that removable storage drive 137 can read

4

the data and instructions. Thus, removable storage unit 140 includes a computer readable storage medium having stored therein computer software and/or data.

In this document, the term “computer program product” is used to generally refer to removable storage unit 140 or hard disk installed in hard drive 135. These computer program products are means for providing software to digital processing system 100. CPU 110 may retrieve the software instructions, and execute the instructions to provide various features of the present invention described below.

3. Generating an Executable File

FIG. 2 is a flowchart illustrating the manner in which an executable file can be generated from program files wherein some of the program files expressly incorporate other program files according to an aspect of the present invention. The flowchart is described with respect to the system of FIG. 1 merely for illustration. However, the features can be implemented in various other environments without departing from the scope and spirit of the present invention. The flowchart begins in step 201, in which control passes to step 210.

In step 210, CPU 110 parses each of the program files read from secondary memory 130 and determines dependency information representing which program files incorporate other program files. In an embodiment, CPU 110 parses each of the program files written in the C programming language to identify all the “#include <filename>” instructions and determines that the parsed program file incorporates all the “filename” program files.

In step 220, CPU 110 stores the dependency information in secondary memory 130. The dependency information can be stored in any form. An example forrr1/format is described in sections below.

In step 240, CPU 110 receives an indication that a program file has been modified. In an embodiment, this indication may be in the form of a list of file names and may be received from a source control program (which keeps track of the modifications related information).

In step 260, CPU 110 identifies program files, which directly (incorporating files) or indirectly (i.e., files incorporating an identified incorporating file) incorporate the modified program file based on the dependency information retrieved from secondary memory 130.

In step 270, CPU 110 marks each of the identified program files as candidates for recompilation. In an embodiment, the marking may be done by changing the modified date (in the underlying operating system) of the identified program files, which would automatically cause the recompilation of the identified program files.

In step 280, CPU 110 recompiles all the marked program files to generate the corresponding compiled files. In a Unix environment where C-programming language is used, object files with extension “.0” are generated from the header and source files.

In step 290, CPU 110 generates the executable file from the compiled files of all the program files. Due to the recompilation of the incorporating files when the corresponding incorporated file is modified, an accurate executable file can be generated. The flowchart ends in step 299.

It may be appreciated that the storage of dependency information in secondary storage facilitates the reuse of the dependency information, other than the eflicient generation of an executable file. In an example, the dependency information may be used to analyze the impact of changing a program file by identifying all the program files that are affected due to the change. The files that need to be recompiled (and/or a count thereof) may be displayed to a user in response to receiving an identifier (e.g., file name) of a program file of interest. As