JP2008003841A - Build processing method, device and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a build processing method that can simply respond to changes of targets and its methods. <P>SOLUTION: A build processing device has a plurality of module configuration description parts 106 to 109 each for describing source files constituting a module in software by identification information on the source files, module link description parts 103 and 104 each for describing modules to be linked by identification information identifying a plurality of module configuration description parts, and build processing description parts 114 and 118 each for describing a building method in association with identification information on the module configuration description parts and module link description parts. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a build processing technique for generating an executable program based on source code.

  Conventionally, when developing large-scale software, the entire software is divided into small units of modules that can be designed independently, and the source code is described for each module and stored as a source file. This source file can be shared by other software.

  In order to generate a program that actually operates by performing a build process by compiling and linking a source file related to such a module, it is necessary to specify the following information to the computer. As this designation information, there are the file name of the source file to be built (compiled / linked), the rules of the build process for these source files and the detailed processing method. Here, the rule of the build process is a rule indicating what kind of process is performed. Further, the detailed processing method includes optimization compilation, include path, and the like.

  As a method for designating information relating to such a build process to a computer, a method using a Make command is generally known.

  This make command is used to build with reference to a Makefile having the contents illustrated in FIG. In FIG. 10, numbers such as “1.” shown at the beginning of the line are line numbers given for explanation (the same applies to FIG. 11).

  In the example of FIG. 10, the file name of the processing target file is described in the 9th line, the rules of the build process are described in the 1st to 3rd lines and the 5th to 8th lines, and the detailed processing method is described in the 4th line. is described.

  When designing / implementing each module using such a make command, one directory is generally created for one module. Then, all source files constituting the module and one Makefile are arranged in the directory. In this Makefile, it is described that all source files of the module are processed.

  By the way, in software development, there are cases where it is desired to specify a plurality of build processing methods for one module. For example, in device control embedded software development, a source file related to the same module is compiled for a plurality of target systems such as an old product CPU, a new product CPU, and a development PC. Hereinafter, “target system” is simply referred to as “target”. The target also includes the meaning of a series of programs to be generated by the build process.

  However, the above-described Makefile can describe only one way of build processing. For this reason, when compiling a source file related to a predetermined module for a plurality of targets, it is necessary to prepare a plurality of makefiles for each target for the module.

  Even if a plurality of makefiles are prepared, there are the following problems. First, the files to be processed in the plurality of Makefiles must match. Therefore, when adding a source file, it is necessary to add the same source file to all Makefiles.

  Secondly, in the Makefile for the same target, it is necessary to unify the description of the build processing method among the modules. This unification is performed manually, which is complicated and has a risk of introducing errors.

  Furthermore, there are also source codes that depend on the target CPU, such as assembly source code. The source code depending on the target type is described in a separate source file for each target type. When describing in Makefile, it is necessary to describe different file names for each source of each source file. This description is also done manually, and there is a risk of being complicated and introducing errors. is there.

  Further, when dividing a plurality of modules, creating a Makefile for each module, and combining these modules to create one program, there is another problem.

  FIGS. 11A to 11C are examples of Makefiles in such a case. Here, it is assumed that a directory is prepared for each module, and each directory has a source file and a Makefile. FIG. 11A shows the Makefile of the Aaa module. The file path name of this Makefile is Aaa / Makefile. FIG. 11B shows the Makefile of the Bbb module. The file path name of this Makefile is Bbb / Makefile.

  FIG. 11C shows a Makefile for linking object files related to two modules Aaa and Bbb. In the Makefile in FIG. 11C, object files related to two modules Aaa and Bbb are linked. Therefore, it is necessary to describe what kind of object file exists as a result of the build processing of those modules (description on the second line in FIG. 11C).

  Further, the details of what kind of file the inside of each module is configured is managed as information closed within the module. Therefore, in the higher-level Makefile such as the Makefile in FIG. 11C that uses these modules as lower-level modules, the internal configuration of these lower-level modules should not be conscious. However, in Makefile, the module configuration cannot be notified to the outside, so the internal configuration of the lower module must be described in the Makefile related to the upper module.

Further, a method for building a large-scale program composed of a combination of a plurality of modules for a plurality of targets is disclosed in Patent Document 1 below. However, in the method according to Patent Document 1, it is necessary not only to select a module to be used, but also to input a large amount of data manually for each target, and there is a risk of errors being mixed. Further, it is necessary to perform the above input operation every time a module to be used is added or changed.
JP 2000-235444 A

  The present invention has been made under such a background, and an object thereof is to provide a build processing method that can easily cope with a change in a target and a method of the build processing.

  In order to achieve the above object, the present invention provides a plurality of module configuration description portions for describing identification information of source files constituting each module in software for each module, and identification information for identifying the plurality of module configuration description portions. A module combination description unit that describes the modules to be combined, and a build process description unit that describes how to perform a build process in association with identification information of the module configuration description unit or the source file for each target; In the build processing method that refers to: a step of accepting designation of the target and the module combination description part, a step of reading the contents of the build process description part corresponding to the designated target, and the designated module combination description The plurality of module configurations to be combined described in the section And having a step of reading the contents of the predicate, and a step of executing a build process based on the content and the content of said plurality of module configuration description part of the build process description part loaded.

  According to the present invention, it is possible to provide a build processing method that can easily cope with changes in the target and the way of the build processing.

  The best mode for carrying out the present invention will be described below with reference to the drawings.

  FIG. 12 is a block diagram showing a hardware configuration of the computer according to the embodiment of the present invention. This computer includes a CPU 1201, a display device 1202 for displaying information, an input device 1203 such as a keyboard and a mouse, a primary storage device 1204 such as a RAM, a secondary storage device 1205 such as an HDD, and a communication device 1206. Hereinafter, the primary storage device 1204 is also simply referred to as a memory 1204. These devices are connected via a bus line 1207 so that they can communicate with each other. The CPU 1201 controls each unit and executes a program corresponding to a processing procedure described later. This program is read from the secondary storage device 1205 to the primary storage device 1204 and executed.

  FIG. 1 is a diagram showing a build processing method according to an embodiment of the present invention. The description content related to the build processing method of FIG. 1 is stored in a storage medium such as a hard disk of the secondary storage device 1205 in the computer shown in FIG.

  As shown in FIG. 1, the build command information 101 uses the build object description unit 110 and the target description unit 102 to specify a build process method for a desired build object and a desired target. . A specific method of specifying the build processing method in the build command information 101 will be described later.

  The build object description unit 110 includes module configuration description units 106 to 109 and module combination description units 103 and 104. The target description unit 102 includes a plurality of build process description units 114 and 118.

  The module configuration description units 106 to 109 of the build target object description unit 110 do not describe each module itself used in the build process, but identify identification information (names of source files) of the build target objects constituting the modules. Only). The module combination description units 103 and 104 are parts that describe which modules should be combined to create an execution program. Also in the module combination description units 103 and 104, only the identification information of the module configuration description units 106 to 109, that is, the names of the module configuration description units 106 to 109 are described.

  The target description unit 102 includes build process description units 114 and 118 corresponding to each target in a one-to-one manner. These build process description units 114 and 118 are configured by build process program description units 111 and 115, build process application rule description units 112 and 116, and build process parameter description units 113 and 117, respectively.

  The build process program description units 111 and 115 include information indicating the location of a program that performs a build process (compilation or the like), for example, a path name of a compiler that actually compiles. In addition, the build process application rule description units 112 and 116 include a method for specifying an input file and an output file in an actual build process according to the characteristics of the build object described in the build object description unit 110, and a build. A method for specifying a compiler to perform processing is described. Also, in the build process parameter description sections 113 and 117, information specified for the compiler that performs the build process in the actual build process, for example, information such as optimization options and macro definitions is described.

  As described above, the build process description units 114 and 118 are prepared for each target. Further, the target description unit 102 stores, for each target, a pair of the target name and the names of the build processing description units 114 and 118 to be applied to the target.

  Based on such a configuration, as the build command information 101 for a desired target, the module combination description units 103 and 104 of the build target object description unit 110 and the target names described in the target description unit 102 A set is specified.

  Therefore, when the internal configuration of a certain module changes, it can be dealt with only by changing the description of the module configuration description units 106-109. Further, when the build processing method of a certain target changes, it can be dealt with only by changing the description of the build processing description sections 114 and 118 corresponding to the target. Furthermore, when a target is added, a new build process description part may be described, and the target and the name of the new build process description part may be described in the target description part 102.

  As described above, even if the internal configuration of the module, the build processing method of the target, or the addition of the target occurs, it is possible to cope with the minimum necessary description change. Moreover, even if a different source file exists for each target, a source file related to a desired target can be designated.

Next, the specific contents of each block shown in FIG. 1 will be described with reference to FIGS.
The numbers such as “1.” shown in FIGS. 2 to 4 are line numbers given for explanation.

[Example of build process description]
First, a specific example of the build process description units 114 and 118 will be described. Each description content exemplified in the present embodiment is stored as a text file arranged in a hierarchical directory structure as shown in FIG. In FIG. 5, a symbol with a symbol “/” added to the end of a line represents a directory name, and a symbol without a symbol “/” added to the end of a line represents a file name. Further, in the working directory shown in FIG. 5, in addition to the file related to the build process description, the file names of the source file and the file related to the compiler / assembler are also described.

  The setting contents of the build process may be divided into individual files and stored as in the above example, or may be stored as a database. Hereinafter, an example of contents of a setting file related to such a build process will be described.

  The target description unit 102 is configured as a file “config / target.conf” illustrated in FIG. 5, and the file “config / target.conf” is described in a form illustrated in FIG. 2. In FIG. 2, “win32pc” is described as the target name in the first line. In the second and subsequent lines, a file name for designating a build process description relating to a target named “win32pc” is described.

  That is, in the second line, “config / win32pc / program.conf” is described as the file name of the files related to the build processing program description units 114 and 118. In the third line, “config / win32pc / rule.conf” is described as the file name of the file related to the build process application rule description units 112 and 116. Further, in the fourth line, “config / win32pc / parameter.conf” is described as the file name of the file related to the build processing parameter description units 113 and 117.

  In the fifth to eighth lines, the same target description relating to the target “h8-2600N” different from the first to fourth lines is described.

  FIG. 3A shows an example of the contents of a file related to the build processing program description units 111 and 115. The description in the file shown in FIG. 3A corresponds to “config / win32pc / program.conf” in FIG.

  In the file of FIG. 3A, a symbol “environment variable” is described on the first line, and the description on the second line and thereafter is environment variable setting information necessary for executing the build program. It is shown.

  The second line describes how the environment variable named “PATH” should be set. In the third line, a symbol “program” is described, and this symbol indicates that the description in the fourth and subsequent lines is program designation information to be used when executing the build process.

  The fourth line describes that when a program related to the symbol “COMPILER” is executed, a program file “gcc.exe” is started. Similarly, the 5th to 6th lines describe that the programs relating to the symbols “ASSEMBLE” and “LINKER” correspond to the program files “as.exe” and “ld.exe”, respectively. Yes.

  FIG. 3B shows an example of the contents of a file related to the build process application rule description units 112 and 116. The file shown in FIG. 3B corresponds to “config / win32pc / rule.conf” in FIG.

  In the file of FIG. 3B, the description “src * / *. Target.c” is described on the first line. This description represents a character string pattern that matches a description of a build target that appears in module combination description units 103 and 104 and module configuration description units 106 to 109 described later. In the second to fourth lines, rules to be applied to the build target that matches the character string pattern in the first line are described.

  That is, on the second line, the description of the build target that matches the character string pattern on the first line, that is, the file name of the input file to be built is “* 1 / * 2.win32pc.c”. It is shown. It should be noted that descriptions such as “* 1” and “* 2” in this file name are expanded by being replaced with a character string corresponding to “*” when they match the character string pattern on the first line.

  On the third line, the output file name of the build process is described in the same format as the input file name. The fourth line describes a program used for the build process. Note that the symbol “COMPILER” described in the fourth line matches the symbol described in the fourth line in FIG. 3A, and “gcc.exe” is used in the actual build process. The program file is started.

  In the 5th to 8th lines, the 9th to 12th lines, and the 13th to 16th lines, as with the 1st to 4th lines, the actual build processing is performed for the build target that matches other character string patterns. The input file name, output file name, and program name are described. Note that “@” described in the 14th line is a generic name for all output file names output in the build process related to the 1st to 13th lines.

  FIG. 3C shows an example of the contents of a file related to the build process parameter description units 113 and 117. The file shown in FIG. 3C corresponds to “config / win32pc / parameter.conf” in FIG.

  In the file of FIG. 3C, the symbol of the program for performing the build process, “COMPILER”, is specified on the first line. The symbol “COMPILER” indicated here matches the symbols in the fourth and eighth lines in FIG. 3B, and the program file “gcc.exe” is included in the actual build process. It is activated.

  The second line describes what detailed parameters should be passed to the program on the first line under what conditions. Note that the description of “$ (INPUT)” and “$ (OUTPUT)” on the second line should be interpreted by replacing the input file name and output file name specified in this build process, respectively. Means. “$ (INPUT) = ˜ModuleA / *. C” in the description on the second line is the same as the program described on the first line when the input file name matches “ModuleA / *. C”. This means that the character string after “:” should be passed as a detailed parameter.

  The third line describes detailed parameters when the input file name does not match the condition of the second line but matches the condition of the third line. In the 4th to 5th lines and the 6th to 7th lines, detailed parameters of the build processing related to “ASSEMBLE” and “LINKER” in FIG. 3B are described, respectively.

  In this embodiment, the description contents of the build process description sections 114 and 118 are described in three files as shown in FIGS. 3A to 3C, but how each description is divided. It is arbitrary whether to make a file, for example, it is also possible to describe each description collectively in one file.

[Example of description in the build object description section]
Next, a specific example of the build target object description unit 110 will be described. Similar to the build process description units 114 and 118, the description content of the build target object description unit 110 is saved in the form of a text file arranged in a directory as shown in FIG.

  4A and 4B show examples of file contents related to the module configuration description units 106 to 109. FIG. The description in the file shown in FIG. 4A corresponds to “Module A / Module A. mod” in FIG.

  In the description of FIG. 4A, there are two modules named “Afunc.c” and “Alogic.s” as build objects constituting the module “ModuleA / ModuleA.mod” shown in FIG. It is shown that.

  The description in the file shown in FIG. 4B corresponds to “Module B / Module b. Mod” in FIG. In the description of FIG. 4B, there are two modules named “Bfunc.c” and “Bsub.target.c” as build objects constituting the module “ModuleA / ModuleA.mod”. Is shown.

  FIG. 4C shows an example of the contents of a file related to the module combination description units 103 and 104. The description in the file shown in FIG. 4C corresponds to “Build / win32pc.mod” in FIG. In FIG. 4C, the first and second lines describe the file names of modules (module configuration description units) to be combined. The third line describes that there is a module named “win32pc-main.c” as a build target, similar to the description in the module configuration description section. The fourth line describes that there is a program named “ProgramAB.exe” as a build target.

  Next, an actual build process based on the descriptions of the build process description units 114 and 118 and the build object description unit 110 will be described with reference to FIGS. The programs related to the build processing in FIGS. 6 to 8 are stored on the hard disk of the secondary storage device 1205, expanded in the memory 1204, and executed by the CPU 1201. The files related to the build process description units 114 and 118 and the build target description unit 110, the source file, and the compiler program shown in FIG. 5 are also stored in the same hard disk.

  For example, the operator opens a window for executing a build command on the display device 1202, and the file or module configuration description unit 106 to the module combination description units 103 and 104 indicating the target name and the build target are displayed on the window. The name of the file according to 109 is input using the input device 1203. The input build command information is read by the CPU 1201 (step S601). Here, it is assumed that “win32pc” is designated as the target name and “Build / win32pc.mod” is designated as the file indicating the build target.

  Next, the CPU reads the target description file (config / target.conf in FIG. 2 described above). Further, the CPU 1201 reads the file contents indicated by the build processing program description file name, the build processing application rule description file name, and the build processing parameter description file name for the target name read in step S601 (step S602).

  As described above, when the target name “win32pc” is specified, specifically, the contents of “config / win32pc / program.conf” that is a file related to the build processing program description ((A) in FIG. 3). Is read. Further, the contents of “config / win32pc / rule.conf” ((B) in FIG. 3), which is a file related to the build process application rule description, are read. Furthermore, the contents of “config / win32pc / parameter.conf” ((C) in FIG. 3), which is a file related to the build processing parameter description, are read. Then, the CPU holds the contents of these read files in the memory 1204.

  Next, based on the file name “Build / win32pc.mod” indicating the build target specified in step S601, the CPU reads the contents of the file (FIG. 4C), that is, the build target description (step). S603). Then, the CPU 1201 executes a build process for the designated target (step S604). Details of the processes in steps S603 and S604 will be described later.

  In the above example, the data shown in FIG. 9 is obtained and stored in the memory 1204 by the processes in steps S601 to S603.

  Next, details of the build target description reading process in step S603 of FIG. 6 will be described based on the flowchart of FIG.

  In the process of reading the build target description, the CPU first reads one line from the first line of the file with the given file name (step S701). In the case of the above specification example, first, the first line of the file “Build / win32pc.mod” shown in FIG.

  Next, the CPU 1201 performs row determination (step S702). In this line determination, whether the line could be read (has not reached the end-of-file), or whether the line starting with “src” or “output” was read, or whether the line starting with “module” was read Determine.

  In the above specification example, since the content “module... / Module A / Module A. mod”, which is the content of the first line, is read, it is determined that the line starting with “module” has been read. When it is determined that the line starting with “module” has been read in this way, the CPU 1201 advances the process to step S704.

  In step S704, the CPU 1201 reads a file “../../Module A / Module A. mod”, that is, a file “Module A / Module A. mod”. After performing the process of step S704, the CPU 1201 returns to step S701, reads the next line of the file with the given file name, and performs the above line determination for the read line in step S702. .

  If the CPU 1201 determines in step S702 that the line read in step S701 is a line starting with “src” or “output”, the CPU 1201 performs input / output / processing determination in step S703. For example, when a line such as “src Afunc.c” in the first line of the file “Module A / Module A. mod” shown in FIG. 4A is read, the input / output / processing determination in step S703 is performed.

  In this input / output / process determination, the CPU 1201 generates and stores a build process input file, an output file, a processing program, and detailed designation information to be given to the processing program as a build processing method of the build target.

  Details of the input / output / processing determination in step S703 will be described with reference to the flowchart of FIG.

  In the input / output / process determination, the CPU 1201 first refers to the build process description information read and held in step S602 in FIG. 6, and the line read in step S701 in FIG. It is determined which rule of the description (FIG. 3B) matches (step S801).

  For example, when the first line of the file “Module A / Module A. mod” is read in step S701 in FIG. 7, the first line is “src Afunc. C”. In this case, as shown in FIG. 3B, the pattern “src Afunc.c” matches the pattern (src * / *. C) on the fifth line of the file “config / win32pc / rule.conf”. To do. Therefore, the input file, output file, and processing program of the build process for the build target shown in the first line are those described in the sixth to eighth lines of the file “config / win32pc / rule.conf”. To decide.

  Next, the CPU 1201 determines an actual input / output file name based on the descriptions “input =” and “output =” in the build process application rule description (step S802). For example, in the above example, the pattern “src Afunc.c” matches the pattern in the fifth line of the file “config / win32pc / rule.conf” in FIG. Therefore, by replacing “*” in “input = * 1 / * 2.c” on the sixth line and “output = * 1 / win32pc / * 2.o” on the seventh line with “Afunc”, Determine the actual input / output file name to be used.

  If “@” is included in the build process application rule description, the CPU 1201 performs the above replacement in a form that lists output file names of all the build processes that have appeared so far.

  Next, the CPU 1201 determines a processing method as follows (step S803). That is, the CPU 1201 obtains a symbol indicating a processing program based on the description of “program =” in the build processing application rule description, and actually uses the contents of the build processing program description ((A) in FIG. 3). Get the name of the processing program. Further, the CPU 1201 refers to the setting of the build processing parameter description ((C) in FIG. 3) based on the symbol indicating the processing program and the input / output file name determined in step S802, and sets parameters to be passed to the processing program. decide.

  Next, the CPU 1201 records data on the determined input / output and processing method in the memory 1204 (step S804). In this processing, the CPU 1201 sets a set of input file names, output file names, processing program names, parameters to be passed to the processing programs, and file names in which the build processing targets are described, determined in steps S802 and S803. Is stored in the memory 1204 as data.

  That is, the CPU 1201 first extracts and sets environment variable setting information from the build process description information read and held in step S602 of FIG. For example, in the above example, the parameter “PATH” described in the item “einventive variable of file“ config / win32pc / program.conf ”in the working directory shown in FIG. 5 is set.

  Further, the CPU 1201 executes the data shown in FIG. 9 obtained by the processing in steps S601 to S603 in FIG. 6 line by line from the top. At this time, the current working directory is a directory in which the “build process target description file” shown in FIG. 9 exists.

  The “processing program” shown in FIG. 9 is executed depending on the “parameters passed to the processing program” in FIG. That is, “*” in “$ (INPUT) =” and “$ (OUTPUT) =” in the second, third, fifth, and seventh lines shown in FIG. 3C indicates the item “input file” shown in FIG. ”And“ output file ”. This replaced file name functions as a relative file name of the current working directory.

  The above input / output / process determination is performed every time the process proceeds to step S703 in FIG. 7, and the set of data is added to the memory 1204 each time. In this way, the build process for the specified target is executed.

  The present invention is not limited to the above-described embodiment, and can be applied to, for example, source code processing other than target build processing.

  For example, as part of the build processing program, create a build processing description that specifies a static analysis tool that warns all modules of dangerous locations in the source code, and specify the build processing description as the embodiment. It is also possible to include in the same manner.

  In addition, in order to measure metrics related to the source code (number of code lines, complexity, etc.), it is possible to include the contents specifying the metrics measurement program as part of the build processing program using the same method as in the embodiment. It is.

  Furthermore, an object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and the computer of the system or apparatus reads the program codes from the storage medium. It is also achieved by executing.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code and the storage medium storing the program code constitute the present invention.

  Examples of the storage medium for supplying the program code include a floppy (registered trademark) disk, a hard disk, a magneto-optical disk, a CD-ROM, a CD-R, a CD-RW, a DVD-ROM, a DVD-RAM, and a DVD. An optical disc such as RW or DVD + RW, a magnetic tape, a nonvolatile memory card, a ROM, or the like can be used. Alternatively, the program code may be downloaded via a network.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) or the like running on the computer based on the instruction of the program code. Includes a case where part or all of the actual processing is performed and the functions of the above-described embodiments are realized by the processing.

  Furthermore, after the program code read from the storage medium is written to a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the expanded function is based on the instruction of the program code. This includes a case where a CPU or the like provided on the expansion board or the expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

It is a functional block diagram which shows the build processing method which concerns on embodiment of this invention. It is a figure which shows the example of a target description. It is a figure which shows the example of a build process description. It is a figure which shows the example of a build target object description. It is a figure which shows the structural example of the working directory for a build process. It is a flowchart which shows the outline | summary of a build process. FIG. 7 is a flowchart illustrating a procedure of a build target description reading process in step S603 of FIG. 6. FIG. It is a flowchart which shows the procedure of the input / output and process determination in step S703 of FIG. It is a figure which shows the example of data obtained by the process of FIGS. 6-8, and was preserve | saved. It is a figure which shows the general description example of Makefile. It is a figure which shows the example of description of the conventional Makefile for a build process. It is a figure which shows the hardware constitutions of the computer which concerns on embodiment of this invention.

Explanation of symbols

101 ... Build designation information 102 ... Target description part 103, 104 ... Module combination description part 106-109 ... Module configuration description part 110 ... Build object description part 114, 118 ... Build process description part 111, 115 ... Build process program description part 112, 116 ... Build process application rule description part 113, 117 ... Build process parameter description part 1201 ... CPU
1202 ... Display device 1203 ... Input device 1204 ... Primary storage device 1205 ... Secondary storage device

Claims (5)

The module to be combined is described by using a plurality of module configuration description sections for describing identification information of source files constituting each module in the software for each module and the identification information for identifying the plurality of module configuration description sections. A build processing method that refers to a module combination description section and a build process description section that describes how to perform a build process in association with identification information of the module configuration description section or the source file for each target,
Receiving the designation of the target and the module combination description part;
Reading the contents of the build process description part corresponding to the specified target;
Reading the contents of the plurality of module configuration description parts to be combined described in the specified module combination description part;
And a step of executing a build process based on the read contents of the build process description part and the contents of the plurality of module configuration description parts.   The build process description part includes a program description part indicating a location of a program for performing the build process, a rule description part to be applied in the build process part, and a parameter description part for specifying a parameter in the process. The build processing method according to claim 1.   The build process description part is characterized in that a part of identification information of an input / output file for an actual build process is described by dummy information to be replaced with the identification information of the module configuration description part The build processing method according to claim 1 or 2.   The build processing apparatus which performs a build process using the build processing method in any one of Claims 1-3.   A computer-readable program for causing a computer to execute the build processing method according to claim 1.

Images