Information processing device, information processing method, and program

Abstract

Provided is an information processing device for compiling a source code that is described in a predetermined programming language and uses a library in which a plurality of versions are present. When the source code to be compiled is received and a definition element defined by the library is used in the received source code, the information processing device receives a version designation that designates either (1) whether to use a definition element of any version among the plurality of versions or (2) whether to allow definition elements of the plurality of versions to coexist, and compiles the received source code in accordance with the version designation, taking a definition element in the received source code as the definition element of any of the plurality of versions.

Description

Information processing device, information processing method, and program

[0001] The present invention relates to an information processing device, an information processing method, and a program for compiling source code.

[0002] To run source code written in a specific programming language on a computer, the source code must be compiled to generate an executable module that the computer can execute. Furthermore, if this source code uses defined elements (classes, functions, variables, etc.) provided by another library (such as a standard library), the object code of that library is linked to the object code output by the compiler to ultimately generate an executable module that the computer can execute.

[0003] In the above-described conventional technology, there may be multiple versions of the same library that differ in their implementation methods. It is expected that these multiple versions of a library, each with different implementation methods, will also have different binary-level interfaces for using the definition elements provided by the library. In such cases, code using multiple versions of the library may be mixed, for example, if an attempt is made to change the version being used midway through a project but, for some reason, the version being used cannot be changed for all parts of the source code at once. This may result in problems such as the generation of an executable module containing inconsistent content, preventing the executable module from executing correctly. Therefore, when multiple different versions of a library exist, it is desirable to be able to clearly indicate which of the multiple versions is being used for the definition elements of the library contained in the source code, and to be able to safely mix multiple versions.

[0004] The present invention has been made in consideration of the above-mentioned circumstances, and one of its objectives is to provide an information processing device, an information processing method, and a program that can effectively use libraries with multiple versions when compiling source code that uses libraries with multiple versions, by specifying the version to be used or allowing multiple versions to be safely mixed.

[0005] An information processing device according to one aspect of the present invention is an information processing device that compiles source code written in a specified programming language and that uses a library of which multiple versions exist, and includes: an acceptance unit that accepts the source code to be compiled, and when a definition element defined in the library is used in the accepted source code, accepts a version specification that specifies either (1) whether to use the definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed; and a compilation unit that compiles the accepted source code in accordance with the version specification, using the definition element in the accepted source code as a definition element of one of the multiple versions.

[0006] Another aspect of the present invention is an information processing device that compiles source code written in a specified programming language and that uses a library of which multiple versions exist, and includes: an acceptance unit that accepts source code that uses definition elements defined in the library as the subject of compilation; and a compilation unit that, if the version of the definition element used in the accepted source code is not explicitly stated, compiles the definition element as a definition element of a predetermined default version from among the multiple versions, and if the version is explicitly stated, compiles the definition element as a definition element of the explicitly stated version.

[0007] An information processing method according to one aspect of the present invention is an information processing method for compiling source code written in a specified programming language and using a library of which multiple versions exist. The information processing method accepts source code to be compiled, and when the accepted source code uses a definition element defined in the library, accepts a version specification that specifies either (1) whether to use the definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed, and compiles the accepted source code in accordance with the version specification, with the definition element in the accepted source code being a definition element of one of the multiple versions.

[0008] According to one aspect of the present invention, there is provided a program for causing an information processing device, which compiles source code written in a predetermined programming language and which uses a library having multiple versions, to accept the source code to be compiled, and, when the accepted source code uses a definition element defined in the library, accept a version designation that specifies either (1) whether to use the definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed, and compile the accepted source code using the definition element in the accepted source code as a definition element of one of the multiple versions in accordance with the version designation. This program may be provided by being stored on a computer-readable, non-transitory information storage medium.

[0009] It is a configuration block diagram showing the configuration of an information processing device according to an embodiment of the present invention. It is a functional block diagram showing the functions of the information processing device according to an embodiment of the present invention. It is a diagram showing an example of a facade header. It is a diagram showing an example of source code in the case where a user-defined element defined in a code to be compiled is used in another code to be compiled.

[0010] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0011] 1 is a block diagram showing the configuration of an information processing device 10 according to one embodiment of the present invention. The information processing device 10 is a personal computer, a server computer, or the like, and as shown in the figure, includes a control unit 11, a storage unit 12, and an interface unit 13. The information processing device 10 is also connected to a display device 14 and an operation device 15.

[0012] The control unit 11 includes at least one processor such as a CPU, and performs various information processing by executing programs stored in the storage unit 12. Specific examples of the processing performed by the control unit 11 in this embodiment will be described later.

[0013] The storage unit 12 includes at least one memory device such as a RAM, and stores the programs executed by the control unit 11 and data processed by the programs.

[0014] The interface unit 13 is an interface for data communication between the display device 14 and the operation device 15. The information processing device 10 is connected to each of the display device 14 and the operation device 15 via the interface unit 13 either wired or wirelessly.

[0015] The display device 14 displays on its screen an image corresponding to a video signal supplied from the information processing device 10 via the interface unit 13. The operation device 15 is, for example, a keyboard or a mouse, and accepts operation input from a user. The information processing device 10 receives, from the operation device 15 via the interface unit 13, an operation signal indicating the content of the operation input accepted by the operation device 15 from the user.

[0016] The information processing device 10 according to this embodiment has a function of compiling source code written by a user in a predetermined programming language and generating an execution module that can be executed by a computer. In the following, as a specific example, the information processing device 10 will compile source code written in the programming language C++.

[0017] Generally, one application program is generated based on multiple source codes generated as separate files. The information processing device 10 does not need to compile these multiple source codes at once; it may compile each source code as a compilation unit individually and output object code corresponding to the source code. Hereinafter, the source code to be compiled by the information processing device 10 in one compilation process will be referred to as the code to be compiled S.

[0018] In this embodiment, the code S to be compiled uses a predetermined library. That is, the code S to be compiled uses at least some of the definition elements defined in the library and provided externally. Here, a definition element is an element whose content is defined somewhere in the source code created by the user and / or a library, and can be used in source code other than the definition location, and may include classes, functions, variables, and type aliases. It may also include various other elements that can be defined in source code, such as enumerations, unions, templates, and concepts.

[0019] In the following, it is assumed that the code S to be compiled uses a C++ standard library (hereinafter simply referred to as standard library L). Furthermore, in this embodiment, it is assumed that the standard library L used by the code S to be compiled has multiple versions, each with a different implementation method and therefore a different binary interface (ABI) for using the definition elements provided by the library. Specifically, in the following explanation, there are two types of standard library L, version 1 and version 2, and the code S to be compiled written by the user will use one or both of these multiple versions. In the following, version 1 of the standard library L will be referred to as standard library L-v1, and version 2 of the standard library L will be referred to as standard library L-v2.

[0020] To enable the use of these multiple versions of the standard library L, the storage unit 12 of the information processing device 10 pre-stores objects for the definition elements provided by the standard library L-v1 and the definition elements provided by the standard library L-v2. As will be described later, these objects do not need to be provided separately for each version, but may be stored in a single library archive. Furthermore, for at least some of the definition elements provided by the standard library L, header files that declare those definition elements are prepared for each of the multiple versions. Hereinafter, definition elements defined in the standard library L are referred to as standard definition elements.

[0021] The functions realized by the information processing device 10 will be described below with reference to the functional block diagram of FIG. 2. As shown in FIG. 2, the information processing device 10 is functionally configured to include a version designation accepting unit 21, a compiling unit 22, and a linking unit 23. These functions are realized by the control unit 11 operating in accordance with one or more programs stored in the storage unit 12. These programs may be provided to the information processing device 10 via a communication network such as the Internet, or may be provided by being stored on a computer-readable information storage medium such as an optical disk.

[0022] When a user compiles code S to be compiled, the version specification accepting unit 21 accepts a specification (hereinafter referred to as "version specification") to use one of multiple versions of definition elements as the version of the standard definition elements used in the code S to be compiled. Furthermore, the version specification accepting unit 21 accepts, as version specifications, specifications to use standard definition elements of standard library L-v1 and specifications to use standard definition elements of standard library L-v2, as well as specifications to allow mixing of multiple versions of standard definition elements. The content of this version specification is referenced when the compiling unit 22, which will be described later, compiles the code S to be compiled.

[0023] As a specific example, the version specification acceptance unit 21 accepts a version specification by referring to an option argument specified by the user on the command line when executing a compiler program. For example, a user specifies a version by setting one of four values ​​to the option argument "-lver-stdlib" as follows: -lver-stdlib=v1 -lver-stdlib=v2 -lver-stdlib=v1+v2 -lver-stdlib=v2+v1. Here, the first and second values ​​specify the use of specific versions of standard definition elements, with v1 specifying version 1 and v2 specifying version 2, respectively. The third and fourth values ​​specify the ability to mix two versions, specifying the version of the standard definition element to be used by default based on the order of the version numbers. That is, v1+v2 specifies version 1 as the default version, and v2+v1 specifies version 2 as the default version. This notation allows the user to specify a default version when specifying versions that allow the use of multiple versions.

[0024] The compiling unit 22 compiles the code S to be compiled based on instructions from the user and outputs object code based on the content of the code S. Furthermore, the compiling unit 22 performs preprocessing, such as expanding macro calls in the code S to be compiled, as necessary, prior to the compilation process.

[0025] Here, the compiling unit 22 executes compilation so that the code to be compiled S uses the specified version of the standard library L, based on the content of the version specification accepted by the version specification accepting unit 21. A specific method for using the specified version of the standard library L will be described later.

[0026] The linking unit 23 links one or more object codes output by the compiling unit 22 with the object code of the standard library L to generate an execution module executable by a computer. At this time, the linking unit 23 links either the object code of the standard library L-v1 or the object code of the standard library L-v2 depending on the compilation result for each standard definition element used in the code to be compiled S. In this way, an execution module of an application program executable by a computer is generated.

[0027] A specific example of a method for making multiple versions of a standard library L available to the code S to be compiled will now be described.

[0028] The standard definition elements of the standard library L used in the code S to be compiled are written with names in the std namespace beginning with std::. The compilation unit 22 switches the namespace of these standard definition elements to another namespace based on the content of the version specification accepted by the version specification acceptance unit 21. This allows the compilation unit 22 to control which of the standard definition elements defined in each of the multiple versions of the standard library L to use. This namespace switching is achieved by the same process as when an inline namespace is declared. In other words, even though an inline namespace is not declared in the code S to be compiled, the compilation unit 22 can perform compilation so as to use the standard definition elements of the version specified by the user by switching the name of the standard definition element to the name of another namespace as if an inline namespace were declared.

[0029] The compilation unit 22 may switch the namespace only when using one of the standard libraries L-v1 and L-v2, rather than switching the namespace for both libraries. For example, assume that the standard definition elements of the standard library L-v1 are declared using the std namespace, and the standard definition elements of the standard library L-v2 are declared using the std::__v2 namespace. In this case, the compilation unit 22 does not need to switch the namespace of the standard definition elements when a version using the standard library L-v1 is specified. On the other hand, when a version using the standard library L-v2 is specified, the compilation unit 22 switches the version of the standard definition elements to be used by hiding the standard definition elements of the standard library L-v1 from the std namespace and exposing the standard definition elements of the standard library L-v2 as if the std::__v2 namespace were declared as an inline namespace in the std namespace. This allows compilation to use the standard definition elements of the version specified by the user by switching the namespace only when the standard library L-v2 is used.

[0030] By selecting the version of the standard library L by switching the name space in this way, it is possible to prevent duplication of symbols for standard definition elements between multiple versions of the standard library L. This allows the object code for the standard library L itself to be collected into a single library archive. This is because different versions of the same standard definition element are managed with different symbol names within the archive. In this way, when the linking unit 23 performs linking, it can link using a single library archive as the link target, regardless of which version of the standard library L is used.

[0031] When the version specification acceptance unit 21 accepts a version specification that allows multiple versions to coexist, one of the multiple versions is defined as the default version (i.e., the version that should be preferentially used). As described above, the version specification acceptance unit 21 accepts a version specification that allows multiple versions to coexist, as well as a default version specification from the user for each compilation. However, this is not a limitation, and the compilation unit 22 may use a specific version that is predefined elsewhere as the default version. In this way, when the version specification acceptance unit 21 accepts a version specification from the user that allows multiple versions to coexist during compilation, the compilation unit 22 can execute a compilation process that mixes multiple versions, even if it does not simultaneously accept a default version specification from the user.

[0032] When a version specification that allows multiple versions to be mixed is specified, the compilation unit 22 performs compilation assuming that the standard definition element of the default version is used, unless otherwise specified in the code to be compiled S. This may be the same processing as when the version specification that uses a specific version is accepted as described above.

[0033] On the other hand, if a predetermined description exists in the code to be compiled S, the compilation unit 22 compiles the standard definition element used at the location specified by the description as a definition element of the version specified by the description. This allows multiple versions of the same standard definition element to be mixed within one code to be compiled S.

[0034] In the case of C++, a pragma can be used to specify the version of the standard library L within the code S to be compiled. For example, if the user wishes to locally use the standard definition elements of the standard library L-v2, the user would write the following pragma within the code S to be compiled: #pragma LVER std_visibility push(v2) Here, LVER is an example of a keyword for using this function, and v2 specifies the version. Similarly, if the user wishes to use the standard definition elements of the standard library L-v1, the user would write the following pragma: #pragma LVER std_visibility push(v1) In response to such a pragma, the compilation unit 22 switches the mode for handling the standard definition elements as a specified version to the specified mode. That is, when the compilation unit 22 accepts these pragmas, it temporarily stores the current mode and performs compilation processing on the standard definition elements in subsequent sections, treating them as if they were the version specified by this pragma.

[0035] To end such mode switching and return to the original mode, the user writes the following pragma in the code S to be compiled: #pragma LVER std_visibility pop In response to this pragma, the compilation unit 22 resets the temporary version specification specified by the pragma above, and performs compilation processing for the portion thereafter in the original mode before the switch. This makes it possible to partially use standard definition elements of any version specified by the creator of the code S to be compiled for specific portions of the code S to be compiled.

[0036] When including another file in the code to be compiled S, it may be inconvenient to process the code in the included file according to the mode switched by this pragma. This is because it is assumed that each included file is written with the assumption that a specific version of the standard definition element is used. Therefore, when including another file from the code to be compiled S, the compilation unit 22 may switch the mode assuming that a pragma specifying the switch to a specific mode is implicitly set for the entire include target file. That is, when including another file, the compilation unit 22 switches to a mode that uses a specific version when compiling the contents of that file, and resets to the original mode when processing of that file is completed. This allows the standard definition element contained in each included file to be compiled as an appropriate version. The mode in which an include target file is processed may be determined based on attribute information of the file, such as the file's storage location or file name. Alternatively, the compilation unit 22 may compile a specific include target file in a mode that uses a predetermined version.

[0037] In the above explanation, the version of the standard definition element is determined based on the specification of a pragma written in the location in the code to be compiled S where the standard definition element is actually used. However, when a macro is used in the code to be compiled S, if the version of the standard definition element is determined according to the specification in the source code at the location after the macro is expanded, there is a possibility that an inconsistency will occur with the version of the standard definition element assumed by the macro. Therefore, when a macro is used, the version of the standard definition element at the location after macro expansion is determined based on the specification of the version of the standard library L written in the location where the macro is defined.

[0038] However, for standard definition elements included in actual arguments passed to a macro, the version of the standard definition element should be determined based on the version specified in the location where the actual argument is described.

[0039] Therefore, when performing macro expansion, the compilation unit 22 temporarily stores in a predetermined storage area the version of the standard library L specified at the location where the macro before expansion is defined and the version of the standard library L specified at the location where the actual arguments passed to the macro are written. After the macro is expanded, the compilation unit 22 determines the version of each standard definition element included in the macro-expanded code based on the temporarily stored information on the version specified at the macro definition location and the version specified at the location where the actual arguments are written. The compilation unit 22 then performs the above-mentioned namespace switching so that the determined version of the standard definition element is used, and then performs compilation. This allows the compilation target code S, which contains a mixture of multiple versions of the standard library L, to be properly compiled even when macros are used.

[0040] Here, we will explain how to handle header files. In this embodiment, it is assumed that a header file that declares a specific standard definition element defined in the standard library L is prepared for each version of the standard library L. When using any version of a standard definition element from a single code S to be compiled, it is necessary to select and include a header file corresponding to the relevant version during compilation. Furthermore, when using multiple versions, it is necessary to include multiple header files corresponding to those multiple versions during compilation. If it were necessary to write such include directives in the code S to be compiled, it would be a burden for the user writing the source code. Therefore, in this embodiment, in addition to the header files for each of the multiple versions, a representative header with the same name that represents both versions (hereinafter referred to as a facade header) is prepared, and the compilation unit 22 preferentially includes this facade header if one exists. By selectively including the header file of the version required for compilation based on the description in this facade header, it becomes possible to include a header containing a declaration required for compilation without changing the description of the include directive in the code S to be compiled. Furthermore, compared to unconditionally including all headers of multiple versions, it is possible to avoid including unnecessary headers and suppress an increase in the time required for compilation processing.

[0041] FIG. 3 shows an example of a facade header. Note that the line numbers at the beginning of each line in the figure are added for explanatory purposes and are not actually necessary. Here, as an example, we will explain the case of including a declaration of the std::string type (hereinafter simply referred to as the string type) for handling character strings in the standard library L. In this example, the header declaring the string type of the standard library L-v1 is located in "include / string", the header declaring the string type of the standard library L-v2 is located in "include / _cxxvers / v2 / string", and the facade header shown in FIG. 3 is located in "include / _cxxvers / facade / string". Furthermore, the compilation unit 22 is set to search the include paths "include / _cxxvers / facade / " where the facade header is stored, "include / " where the header of the standard library L-v1 is stored, and "include / _cxxvers / v2 / " where the header of the standard library L-v2 is stored, in that order. Therefore, if the following is set in the code S to be compiled: <string>If there is a directive instructing the inclusion of "include / _cxxvers / facade / ", and the facade header is placed in "include / _cxxvers / facade / ", the compilation unit 22 will preferentially select the facade header as the target for inclusion.

[0042] _CXXVERS_MODE(), referenced on line 3 of the facade header, is a macro that returns the value of the current macro replacement version. This macro replacement version is used to expand macros used in the header of the standard library L included from the facade header so that standard definition elements are declared in a namespace corresponding to the specified version. In this example, control over macro expansion according to the specified version is realized by the contents of <_cxxvers / config.h>, included on line 1. The initial value of the macro replacement version is set to 2, and is set to 1 when a version specification that uses standard definition elements of version 1 is specified. __LIBC_CXX_MIXED_VERSION__ is a macro defined by the compilation unit 22 and is set when a version specification that allows multiple versions to be mixed is specified.

[0043] If the macro replacement version is 2 and the mixed version mode is specified, the current macro replacement version is temporarily saved, then the macro replacement version is set to 1 (lines 3-5), and then <string>The header is included (line 7). Here, the include path is searched from the path where the current facade header exists onwards, so the header of standard library L-v1 is included. Furthermore, because the value of the macro replacement version is set to 1, macros related to standard library L in the included header are expanded so that standard definition elements are declared in the namespace corresponding to version 1. The value of the macro replacement version is then reset and returns to the value temporarily saved in line 4 (here, 2) (lines 12-15).

[0044] On the other hand, if the value of the macro replacement version is 1 or less, the header of the standard library L-v1 is included as is (lines 8-9). In this case, the value of the macro replacement version is assumed to be 1, so the macros in the included header are expanded to content corresponding to version 1, just as in the case of inclusion on line 7 mentioned above. Note that in this case, the value of the macro replacement version has not changed, so unlike the previous case, there is no need to reset the value of the macro replacement version.

[0045] Furthermore, if the value of the macro replacement version is 2, the string type header defined in the standard library L-v2 is included (lines 17-19). Note that because the header of the standard library L-v2 is saved in a different directory, the include destination is specified using a relative path (line 18). In this case, since the value of the macro replacement version is 2, the macros in the included header are expanded so that standard definition elements are declared in the namespace corresponding to version 2.

[0046] By including this facade header, the compilation unit 22 can include the header file of the required version of the standard definition element. Specifically, when the use of standard library L-v1 is specified, the compilation unit 22 includes the header file of standard library L-v1 by setting the value of the macro replacement version to 1. When the use of standard library L-v2 is specified, the value of the macro replacement version is set to the initial value of 2, so the header file of standard library L-v2 is included. Furthermore, when a mixture of multiple versions is specified, the header files of both versions are included by setting the __LIBC_CXX_MIXED_VERSION__ macro. This allows the compilation target code S to include the required headers simply by including the facade header, without having to specify whether to include headers for each version.

[0047] Furthermore, when the compiler 22 includes a header of the standard library L-v1 or L-v2 from the facade header, it switches the value of the macro replacement version to the corresponding value before including it, which allows the macros used in the included header to be expanded to content appropriate for the corresponding version.

[0048] The above explanation describes an example of a facade header when a header with the same name exists in both standard libraries L-v1 and L-v2. For standard definition elements for which only one header exists, the corresponding version header can be included according to the priority of the include path without using a facade header. However, if a macro needs to be used to declare a standard definition element in the namespace of the corresponding version, a facade header can be placed, the value of the macro replacement version can be switched within the facade header, and then the corresponding version header can be included. For example, if only the header of standard library L-v1 exists and the macro used within it needs to be expanded in the corresponding version, a facade header including a control to switch the value of the macro replacement version can be created and placed, similar to the example shown in Figure 3. However, in this case, there is no need to include the header of standard library L-v2, so the code from line 17 onwards in the example shown in Figure 3 is unnecessary.

[0049] Also, if the standard libraries L-v1 and L-v2 have headers with the same name and it is necessary to define both headers, create a facade header that includes both. For example, by creating a facade header in which the "&& defined(__LIBC_CXX_MIXED_VERSION__)" statement on the third line of the facade header shown in Figure 3 has been deleted, it is possible to include both the headers of the standard libraries L-v1 and L-v2 when the macro replacement version value is 2 (the default value).

[0050] Furthermore, even when recursively including a header from within another header, the necessary headers can be included appropriately by using the facade header as shown in FIG.

[0051] As a specific example, suppose a header declaring a definition element of a standard library L-v1 attempts to include a header declaring a definition element of another standard library L-v1 (here, a header declaring a string type) from a header declaring a definition element of another standard library L-v1. If a facade header corresponding to this string type header is available, the compilation unit 22 will include this facade header with the macro replacement version value set to 1. Then, the string type header of standard library L-v1 is included from this facade header (line 9). Since the _STRING_CXXVERS_MODE_RESET_ macro on line 6 is not set, the processing on line 13 is skipped, the macro replacement version value remains 1, and the value is reset after returning to the original header. Note that, since standard library L-v2 is assumed to be a newer version than standard library L-v1, including the header of standard library L-v2 from the header of standard library L-v1 is not anticipated.

[0052] On the other hand, when including a string type header from a header that declares a definition element of the standard library L-v2, if a facade header is prepared, the compilation unit 22 first includes this facade header. At this time, the value of the macro replacement version is set to 2. Then, using the control described above, the compilation unit 22 includes the string type header of the standard library L-v2, and if a mixture of multiple versions is specified, it also includes the string type header of the standard library L-v1. In this way, even when including a header of a standard definition element from another header, by going through the facade header, it is possible to include the required version of the header with the corresponding macro replacement version value set.

[0053] According to the processing described so far, when compiling only one code to be compiled S, the user can selectively use or mix multiple versions of the standard library L used in that code to be compiled S. However, when multiple codes to be compiled S are compiled separately and then linked to generate an execution module, there is a risk of inconsistencies in the versions of the standard library L between the multiple codes to be compiled S. Therefore, the following describes controls for preventing such inconsistencies.

[0054] Specifically, an example will be described in which a definition element defined in one of multiple source codes and used by other source codes uses a standard library L. Hereinafter, a definition element defined in source code created by a user in this manner will be referred to as a user-defined element. For ease of explanation, source code that defines a user-defined element that can be used by other source codes will be referred to as code to be compiled S1, and source code that uses the user-defined element defined in code to be compiled S1 will be referred to as code to be compiled S2. Code to be compiled S1 may be source code that includes user-defined elements such as classes and functions that are commonly used by multiple source codes, such as a library created by a user.

[0055] 4 shows a specific example of such source code. In this example, there are three source code files: a header file ah containing declarations of a structure A and a function func, func.cpp, which is code S1 to be compiled that contains a definition of the function func, and test.cpp, which is code S2 to be compiled that uses the function func. Both func.cpp and test.cpp include ah.

[0056] Now, let's assume that the code to be compiled S1 and the code to be compiled S2 are compiled in a mode that uses different versions of the standard library L by using the version specification method described above. Then, even if the compilation of each code to be compiled S is successful, the object codes generated by these compilations will reference different versions of the string class. Therefore, if an attempt is made to link these object codes as is and execute the generated executable module, an inconsistency will occur when the function func is executed.

[0057] Specifically, when the code to be compiled S1 is compiled, object code for two functions, func(std::string s) and func(A a), is generated, and symbols representing the start addresses of the two functions are generated. When the code to be compiled S1 is compiled in a mode that uses the standard library L-v1, the symbols for these two functions are func(std::basic_string<...>) and func(A). Here, the basic_string<...> portion represents the actual type in the standard library L-v1 of the string class, which is defined under the alias std::string. Also, here, the definition elements of the standard library L-v1 are expressed using names in the std namespace. On the other hand, when the code to be compiled S1 is compiled in a mode that uses the standard library L-v2, the symbols for the two functions, func(std::__v2::basic_string<...>) and func(A), are generated. In this example, std::string is converted to a name in the std::__v2 namespace. In this example, the part "basic_string<...>" represents the actual type of std::string defined in the standard library L-v2.

[0058] Furthermore, when the code to be compiled S2 is compiled, object code is generated that calls two functions, func(std::string s) and func(A a). The object code generated here is code that makes calls using the same symbols as when the code to be compiled S1 is compiled, depending on which standard library L is used in the mode in which the code to be compiled S2 is compiled. In other words, when the code to be compiled S2 is compiled in a mode in which standard library L-2 is used, the function call for func(s) attempts to call the function defined in the code to be compiled S1 using the symbol func(std::__v2::basic_string<...>), and the function call for func(a) attempts to call the function defined in the code to be compiled S1 using the symbol func(A).

[0059] For example, suppose code S1 to be compiled is compiled in a mode that uses standard library L-v1, and code S2 to be compiled is compiled in a mode that uses standard library L-v2. Then, for function func(std::string s), the symbols generated during compilation of code S1 and code S2 to be compiled do not match because they contain different string class types. Therefore, the linking unit 23 cannot link these object codes and generates an error. On the other hand, for function func(A a), both symbols match, func(A), so it is assumed that the linking unit 23 would not generate an error as is. However, structure A contains member s of the string type in standard library L, and this member s is used by function func(A a). Therefore, if code S1 to be compiled, which defines a user-defined element that uses a standard-defined element in standard library L, and code S2 to be compiled, which uses this user-defined element, are compiled using different versions of standard library L, a mismatch in the versions of standard library L may cause inconsistencies.

[0060] Therefore, in this embodiment, the compiling unit 22 associates a value (identification value) for identifying each user-defined element in the code S to be compiled, and the linking unit 23 detects such inconsistencies by referring to this identification value. Such control can be achieved by utilizing the absolute symbol function that has traditionally been provided in C++ linker programs.

[0061] Specifically, when compiling the code to be compiled S, the compilation unit 22 determines the value of an absolute symbol to be used as an identification value for a user-defined element in the code to be compiled S, associates the determined value with the corresponding user-defined element, includes it in the object code, and outputs it. At this time, if it is specified that the same version of the standard library L be used for multiple codes to be compiled S, the compilation unit 22 determines the value of the absolute symbol so that user-defined elements with the same symbol name have the same value. Conversely, if it is specified that different versions of the standard library L be used for multiple codes to be compiled S, the compilation unit 22 determines the value of the absolute symbol for each symbol so that the value of the absolute symbol for user-defined elements with the same symbol name will be different for each version of the standard library L.

[0062] For example, the compilation unit 22 determines the value of such an absolute symbol for each user-defined element by calculating a hash value of the information (including version information) of the standard definition element in the standard library L that is used by that user-defined element. In this way, for user-defined elements with the same name, if different versions are specified at compile time, different hash values ​​will be obtained, and if the same version is specified, the same hash value will be obtained. In other words, a value unique to each version of the standard definition element used by the user-defined element is determined as the value of the absolute symbol associated with that user-defined element.

[0063] Thereafter, when linking object code, the linking unit 23 verifies whether the absolute symbol values ​​of the user-defined elements to be linked match, and outputs an error if the verification results in a mismatch. This makes it possible to detect in advance any mismatches when attempting to link object code that uses standard-defined elements defined in different versions of the same standard library L. Note that such absolute symbol verification itself may be achieved by a function related to absolute symbols that has traditionally been included in linker programs. However, in this embodiment, when a mismatch in absolute symbol values ​​is detected, the linking unit 23 may present the user with an error message indicating that the cause is a mismatch in the versions of the standard library L. This makes it easier for the user to identify the cause of the error.

[0064] The compilation unit 22 does not need to newly determine absolute symbol values ​​for all user-defined element names that appear in the code S to be compiled. Specifically, the compilation unit 22 determines absolute symbol values ​​for a user-defined element when a user-defined element including a standard-defined element in the standard library L is newly defined, or when the user-defined element is used in a manner that references an internal structure (such as a member of a structure). On the other hand, when a user-defined element is simply declared (such as when a class type is declared), it is not necessary to determine absolute symbol values ​​for the user-defined element. In the case of a class template, the value of the absolute symbol is not required when the class template is defined, but when the class template is instantiated (when an instance of the class is generated), the value of the absolute symbol is determined for the instance.

[0065] Furthermore, when determining whether a user-defined element uses a standard-defined element, the compilation unit 22 does not need to recursively search all user-defined elements used by that user-defined element to determine whether they internally use standard-defined elements. It can simply determine the absolute symbol value for the user-defined element that uses the standard-defined element. For example, if function func uses structure B, which includes structure A as a member and uses a standard-defined element, the absolute symbol value for structure A is determined when structure A is defined. Since structure A is used when structure B is defined, the absolute symbol value for structure A is determined according to the version of the standard library L. The absolute symbol value is compared with the absolute symbol value when structure A was defined, and if there is a mismatch, an error is detected. Therefore, for structure B, which does not directly use a standard-defined element, inconsistencies due to different versions of the standard library L can be avoided without having to re-determine the absolute symbol value.

[0066] As described above, the information processing device 10 according to this embodiment makes it easy to compile each code S to be compiled using a different version of the standard library L, or to use multiple versions of the standard library L from one code S to be compiled. Furthermore, by preventing inconsistencies that arise when multiple versions are mixed together, multiple versions can be used safely.

[0067] It should be noted that the embodiments of the present invention are not limited to those described above. For example, the above description has been given of a case in which two versions of the standard library L are used. However, this is not a limitation. The information processing device 10 according to this embodiment may also apply the techniques described above to use or mix three or more versions of the standard library L. Furthermore, the information processing device 10 according to this embodiment may use multiple versions of any library, not limited to the standard library L, using the techniques described above. Furthermore, in this embodiment, the code to be compiled S is written in the programming language C++. However, this is not a limitation. Source code written in other programming languages ​​may also be compiled by the information processing device 10 according to this embodiment.

[0068] In the above description, the method by which the user specifies the version of the standard library L to be used during compilation and the method of describing the source code when multiple versions are mixed are merely examples, and various methods may be adopted to achieve similar functions. For example, as a method for specifying the version of the standard library L to be used, a default specification may be set in advance using a configuration file or environment variable, and the version specification acceptance unit 21 may adopt the default specification if no other specification is accepted during compilation. Furthermore, the user may be able to select a version specification option using a predetermined command or the like prior to compilation, and the version specification acceptance unit 21 may accept the version specification according to the option selected by the user during compilation. Furthermore, the description for switching versions in the source code may be written in a section that is considered a comment in the language specification.

[0069] It should be noted that the functions provided by the components described herein may be implemented by any circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, configured or programmed to provide the described functions. A processor includes transistors and other circuits and is considered to be a circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in a memory.

[0070] In this specification, a circuit, unit, or means is hardware that is programmed to realize a described function or that performs that function. The hardware may be any hardware disclosed in this specification or any hardware that is programmed to realize or known to perform the described function. If the hardware is a processor, which is considered to be a type of circuit, the circuit, means, or unit is a combination of hardware and software used to operate the hardware and / or processor.

[0071] The present disclosure may include the following aspects: [Item 1] An information processing device that compiles source code written in a predetermined programming language and that uses a library of multiple versions, the information processing device comprising: a circuit configured to accept source code to be compiled, and, when the accepted source code uses a definition element defined in the library, accept a version designation that specifies either (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed, and compile the accepted source code in accordance with the version designation, using a definition element in the accepted source code as a definition element of one of the multiple versions. [Item 2] An information processing device that compiles source code written in a predetermined programming language and that uses a library of multiple versions, comprising: a circuit configured to accept, as a compilation target, source code that uses a definition element defined in the library, and to compile a definition element used in the accepted source code as a definition element of a predetermined default version from among the multiple versions if the version of the definition element to which the definition element belongs is not explicitly specified, or to compile as a definition element of the explicitly specified version if the version is explicitly specified. [Item 3] The information processing device according to item 2, wherein the circuit accepts a version specification that specifies either (1) to use a definition element of one of the multiple versions, or (2) to allow the multiple versions of definition elements to be mixed, and if the specification of (2) is accepted, also accepts specification of a default version, and if the specification of (2) is accepted, to compile a definition element used in the accepted source code as a definition element of the specified default version if the version of the definition element to which the definition element belongs is not explicitly specified, or to compile as a definition element of the explicitly specified version if the version is explicitly specified.[Item 4] The information processing device according to any one of items 1 to 3, wherein the definition elements defined in the library include at least any of a class, a function, a variable, and an alias of a type. [Item 5] The information processing device according to any one of items 1 to 3, wherein the circuit, for a user-defined element that is defined in source code and uses a definition element defined in the library, when compiling source code including the user-defined element, outputs a different identification value according to the version of the definition element of the library used by the user-defined element, in association with a symbol representing the user-defined element, and when linking multiple objects obtained by compiling different source codes, compares the identification values ​​associated with the symbols representing the user-defined element included in each of the multiple objects to determine whether the objects can be linked. [Item 6] In the information processing device according to item 1, when the source code includes an instruction to include a header that declares a predetermined definition element defined in the library, the circuitry preferentially includes a representative header prepared in advance for the predetermined definition element, and selectively includes one or more headers to be used for compilation from among a plurality of headers that declare the predetermined definition element corresponding to each of the plurality of versions, based on a description of the representative header and the content of the version designation. [Item 7] In the information processing device according to item 6, when including one or more headers that declare the predetermined definition element corresponding to each of the plurality of versions, the circuitry controls, based on a description of the representative header, to expand a macro used in the included header into content according to the version corresponding to the header.[Item 8] An information processing method for compiling source code written in a predetermined programming language and using a library of which multiple versions exist, comprising: accepting source code to be compiled; and, when the accepted source code uses a definition element defined in the library, accepting a version specification that specifies either (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed; and compiling the accepted source code in accordance with the version specification, with the definition element in the accepted source code being one of the definition elements of the multiple versions. [Item 9] A computer-readable, non-transitory information storage medium that stores a program for causing an information processing device that compiles source code written in a predetermined programming language and that uses a library of which multiple versions exist to accept source code to be compiled, and when the accepted source code uses a definition element defined in the library, accept a version designation that specifies either (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed, and compile the accepted source code in accordance with the version designation, using the definition element in the accepted source code as a definition element of one of the multiple versions.

[0072] 10 Information processing device, 11 Control unit, 12 Storage unit, 13 Interface unit, 14 Display device, 15 Operation device, 21 Version designation acceptance unit, 22 Compilation unit, 23 Link unit< / string> < / string>

Claims

1. An information processing device that compiles source code written in a specified programming language and that uses a library for which multiple versions exist, comprising: an acceptance unit that accepts source code to be compiled, and when the accepted source code uses a definition element defined in the library, accepts a version designation that specifies either: (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed; and a compilation unit that compiles the accepted source code in accordance with the version designation, with the definition element in the accepted source code being one of the definition elements of the multiple versions.

2. An information processing device that compiles source code written in a specified programming language and that uses a library of multiple versions, comprising: an accepting unit that accepts source code that uses definition elements defined in the library as the subject of compilation; and a compiling unit that, if the version of the definition element used in the accepted source code is not explicitly stated, compiles the definition element as a definition element of a predetermined default version from among the multiple versions, and compiles the definition element as a definition element of the explicitly stated version if it is explicitly stated.

3. An information processing device according to claim 2, wherein the acceptance unit accepts a version designation that specifies either (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow mixing of definition elements of the multiple versions, and when the designation (2) is accepted, also accepts the designation of a default version, and when the compilation unit accepts the designation (2), compiles the definition element used in the accepted source code as a definition element of the specified default version if it is not explicitly stated which version the definition element belongs to, or as a definition element of the explicitly stated version if it is explicitly stated.

4. An information processing device according to any one of claims 1 to 3, wherein the definition elements defined in the library include at least any one of a class, a function, a variable, and an alias of a type.

5. An information processing device according to any one of claims 1 to 3, wherein when compiling source code including a user-defined element that is defined in source code and uses a definition element defined in the library, the compilation unit outputs a different identification value associated with a symbol representing the user-defined element depending on the version of the definition element of the library used by the user-defined element, and the information processing device further includes a linking unit that, when linking multiple objects obtained by compiling different source codes, compares the identification values ​​associated with the symbols representing the user-defined element included in each of the multiple objects to determine whether or not they can be linked.

6. An information processing device as described in claim 1, wherein when the source code contains an instruction to include a header that declares a specified definition element defined in the library, the compilation unit preferentially includes a representative header prepared in advance for the specified definition element, and selectively includes one or more headers to be used for compilation from among a plurality of headers that declare the specified definition element corresponding to each of the multiple versions based on the description of the representative header and the contents of the version specification.

7. An information processing device according to claim 6, wherein when including one or more headers that declare the specified definition elements corresponding to each of the multiple versions, the compilation unit controls, based on the description of the representative header, to expand macros used in the included header into content corresponding to the version corresponding to the header.

8. An information processing method for compiling source code written in a specified programming language and using a library that has multiple versions, comprising the steps of: accepting source code to be compiled; and, when the accepted source code uses a definition element defined in the library, accepting a version designation that specifies either: (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed; and compiling the accepted source code in accordance with the version designation, with the definition element in the accepted source code being one of the definition elements of the multiple versions.

9. A program for causing an information processing device that compiles source code written in a specified programming language and that uses a library that has multiple versions to accept the source code to be compiled, and when the accepted source code uses a definition element defined in the library, accept a version designation that specifies either: (1) whether to use a definition element of one of the multiple versions, or (2) whether to allow the definition elements of the multiple versions to be mixed, and compile the accepted source code in accordance with the version designation, with the definition element in the accepted source code being one of the definition elements of the multiple versions.