Code construction method and device, electronic equipment and storage medium

Abstract

The invention discloses a code construction method and device, electronic equipment and a storage medium, and relates to the technical field of code development.The method comprises the steps that a first version and a second version of a first code library which a to-be-constructed code needs to depend on are obtained, and under the condition that the first version and the second version are not compatible, the to-be-constructed code is constructed; determining a target segmentation version in the first version and the second version; a link between the target segmentation version and the to-be-constructed code is configured, the link comprises a local isolation instruction, and the local isolation instruction is used for instructing the target segmentation version to call local parameters when the target segmentation version runs; and compiling the to-be-constructed code, and removing dependence between the target segmentation version and the to-be-constructed code after the to-be-constructed code is compiled, so that the to-be-constructed code is compatible with the first version and the second version during running. The technical problem that the code construction efficiency is low under the condition that codes need to depend on code libraries of different versions is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of code development technology, and in particular to a code construction method, device, electronic device, and storage medium. Background Art

[0002] During software development, code often relies on multiple layers of libraries to implement specific functionality. For example, a developer might build code that relies on different code libraries, such as version v1 of library a and library b. Library b, in turn, relies on another version of library a, such as v2. However, v1 and v2 are incompatible, and both need to run in the same process, making it impossible to successfully compile and run the code. If two incompatible versions need to run in the same process, significant adjustments must be made to one of the versions. Even after these adjustments, code may still run abnormally, leading to inefficient code builds.

[0003] Therefore, when the code needs to rely on different versions of the code base, there is a technical problem of low code building efficiency.

[0004] The above content is only used to assist in understanding the technical solutions of the embodiments of the present application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of the embodiments of the present application is to provide a code construction method, device, electronic device and storage medium, aiming to solve the technical problem of low code construction efficiency when the code needs to rely on code libraries of different versions.

[0006] To achieve the above objectives, an embodiment of the present application provides a code construction method, the method comprising:

[0007] Obtaining a first version and a second version of a first code library that the code to be built depends on, and if the first version and the second version are incompatible, determining a target split version between the first version and the second version;

[0008] Configuring a link between the target split version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target split version to call local parameters when running;

[0009] Compile the code to be built, and after the code to be built is compiled successfully, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

[0010] In one embodiment, when a compilation error occurs in the code to be built, determining a target compilation isolation object;

[0011] Configuring local compilation items for the target compilation isolation object and compiling the target compilation isolation object;

[0012] After the target compilation isolation object is compiled successfully, recompile the code to be built so that the code to be built is compiled successfully;

[0013] The local compilation item is used to instruct the target compilation isolation object to compile local parameters during compilation, and to close external visibility permissions to the local parameters of the target compilation isolation object.

[0014] In one embodiment, the step of determining a target compilation isolation object includes:

[0015] If an intermediate code library exists between the target segmented version and the code to be built, determining the intermediate code library as a target compilation isolation object, wherein the code to be built depends on the target segmented version through the intermediate code library;

[0016] In a case where a package library of the target split version exists between the target split version and the code to be built, the package library is determined to be a target compilation isolation object, wherein the code to be built depends on the target split version through the package library.

[0017] In one embodiment, the step of compiling the target compilation isolate object includes:

[0018] Configure the isolation name of the target compilation isolation object in the preset compilation file;

[0019] The target compilation isolation object is compiled by configuring a preset compilation file with the isolation name.

[0020] In one embodiment, the step of configuring a link between the target split version and the code to be built includes:

[0021] In a case where an intermediate code library exists between the target segmented version and the code to be built, and no encapsulation library of the target segmented version exists, configuring a link to the target segmented version in the intermediate code library;

[0022] In a case where there is an encapsulation library between the code to be built and the target split version and no intermediate code library exists, configuring a link to the target split version in the encapsulation library;

[0023] In the case that a package library and an intermediate code library exist between the code to be built and the target split version, a link to the target split version is configured in the package library, or a link to the target split version is configured in the intermediate code library.

[0024] In one embodiment, the step of removing the dependency between the target split version and the code to be built includes:

[0025] In the case where the link is configured as a package library between the target split version and the code to be built, calling a preset dependency removal tool to remove the dependency between the package library and the target split version, so as to remove the dependency between the target split version and the code to be built;

[0026] In the case where the link is configured as an intermediate code library between the target split version and the code to be built, a preset dependency removal tool is called to remove the dependency between the intermediate code library and the target split version, so as to remove the dependency between the target split version and the code to be built.

[0027] In one embodiment, after removing the dependency between the target split version and the code to be built, the method further includes:

[0028] Run the code to be built;

[0029] During the execution of the code to be built, the code to be built supports direct access to the target retained version to call the local parameters of the target retained version. When the code to be built needs to call the local parameters of the target split version, the code to be built calls the local parameters of the target split version through the link; the target retained version is the version of the first version and the second version from which the dependency has not been removed.

[0030] In addition, to achieve the above-mentioned purpose, an embodiment of the present application provides a code construction device, the device comprising:

[0031] an acquisition module, configured to acquire a first version and a second version of a first code library on which the code to be built depends, and if the first version and the second version are incompatible, determine a target split version between the first version and the second version;

[0032] a configuration module, configured to configure a link between the target segmented version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target segmented version to call local parameters when running;

[0033] The compatibility module is used to compile the code to be built, and after the code to be built is compiled, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

[0034] In addition, to achieve the above-mentioned object, an embodiment of the present application further provides an electronic device, comprising at least one processor and a memory communicatively connected to the at least one processor;

[0035] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute to implement the code construction method as described above.

[0036] In addition, to achieve the above-mentioned purpose, an embodiment of the present application also provides a computer-readable storage medium, on which a program for implementing the code construction method is stored. When the program of the code construction method is executed by a processor, the steps of the code construction method as described above are implemented.

[0037] In addition, to achieve the above-mentioned purpose, an embodiment of the present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned code construction method when executed by a processor.

[0038] One or more technical solutions proposed in the embodiments of the present application have at least the following technical effects: when the first version and the second version that the code to be built depends on are incompatible, the target split version can be determined in the first version and the second version, and a link between the target split version and the code to be built can be configured so that the code to be built can obtain the parameters in the target split version through the link. At the same time, due to the presence of local isolation instructions in the link, the target split version calls local parameters when it is running, and does not call parameters of other versions in the same code base, which makes it easier for the first version and the second version to be compatible when the code to be built is subsequently built.

[0039] Furthermore, since the present application will compile the code to be built after configuring the link between the code to be built and the target split version to ensure the accuracy of the link configuration, the dependency between the target split version and the code to be built can be removed after the code to be built is compiled, so that the code to be built will not directly access the target split version when it is running, but will obtain the local parameters in the target split version through the link when the parameters in the target split version are needed, and will not obtain the parameters in the first and second versions at the same time. Therefore, when the code to be built is running, the first and second versions will not be accessed at the same time due to the same name, thereby reducing the conflict between the first and second versions (in the same generation In different versions of the code library, the parameters corresponding to the same name may be different. If the same symbol accesses different parameters, there will be a conflict). As a result, the code to be built can be compatible with the first version and the second version when running, because the dependency between the code to be built and the target split version is removed, and a link is configured between the code to be built and the target split version. Therefore, the compatibility between the first version and the second version can be achieved without affecting the original function of the code to be built. In this embodiment, no major modifications are required. It is only necessary to configure the link between the target split version and the code to be built and remove the dependency between the target split version and the code to be built, thereby improving the construction efficiency of the code to be built. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the embodiments of the present application, and together with the specification are used to explain the principles of the embodiments of the present application.

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0042] Figure 1 This is a flow chart of an embodiment of the code construction method of the present application;

[0043] Figure 2 This is a dependency diagram of the second version of the code construction method in the embodiment of the present application, which is an indirect dependency relationship;

[0044] Figure 3 This is a dependency diagram of the first version of the code construction method in the embodiment of the present application, which is an indirect dependency relationship;

[0045] Figure 4 This is a dependency diagram in which the first version and the second version in the code construction method of the embodiment of the present application are both indirect dependencies;

[0046] Figure 5 The intermediate code library of the example of the code construction method of the embodiment of the present application includes a schematic diagram of the dependency relationship between the source code packaging library and the code source code;

[0047] Figure 6 A schematic diagram of the dependency relationship of another example of the code construction method of the embodiment of the present application;

[0048] Figure 7 This is a schematic diagram of the module structure of the code construction device of the embodiment of the present application;

[0049] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the code construction method in the embodiment of the present application.

[0050] The purpose, functional features and advantages of the embodiments of the present application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the embodiments of the present application and are not intended to limit the embodiments of the present application.

[0052] In order to better understand the technical solutions of the embodiments of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0053] Modern program development often relies on various frameworks or software libraries, which are often shared as dynamic libraries. Even for open-source versions, users rarely modify their content and often compile them into dynamic libraries. Alternatively, third parties may package the code into libraries to avoid exposing code details. Furthermore, different versions of the same library are often incompatible and cannot be mixed.

[0054] However, during the development process, the following problems often occur: the code built by the developer calls functions of library a, and library a cannot be rewritten and compiled or is not suitable for rewriting and recompilation. For example, the changes may be too large or cannot be changed, and library a depends on version v01 of library b. The code built by the developer also depends on library b, but the version is different, v02, and the built code is not suitable for modification to the API (Application Programming Interface) function of version v01 of library b. However, versions v01 and v02 of library b are incompatible. The built code, library a, and the v01 and v02 versions of library b that library a depends on must be used in the same process. This will cause the built code to fail to compile or run.

[0055] The current approach is to organize the code for version b v01 in one process and version b v02 in another, using inter-process communication. However, this approach requires significant changes and affects communication link latency, which in turn affects the efficiency of the code being built. Alternatively, functions from version b v01 can be encapsulated in library a. However, if library a uses many functions from library b, this also involves significant changes. Furthermore, changes to library a may be impossible, so this approach may not be feasible.

[0056] Therefore, the embodiment of the present application provides a method of determining the target split version in the first version and the second version when the first version and the second version that the code to be built depends on are incompatible, and configuring a link between the target split version and the code to be built so that the code to be built can obtain the parameters in the target split version through the link. At the same time, due to the presence of local isolation instructions in the link, the target split version calls the local parameters, and the local parameters of the target split version cannot be seen from the outside, so that the local parameters of at least one version of the first version and the second version will not be accessed by versions other than the version itself, thereby facilitating compatibility between the first version and the second version in the subsequent code to be built.

[0057] Furthermore, since the present application will compile the code to be built after configuring the link between the code to be built and the target split version to ensure the accuracy of the link configuration, the dependency between the target split version and the code to be built can be removed after the code to be built is compiled, so that the code to be built will not directly access the target split version when it is running, but will obtain the local parameters in the target split version through the link when the parameters in the target split version are needed, instead of obtaining the parameters in the first and second versions at the same time. Therefore, when the code to be built is running, the first and second versions will not be accessed at the same time due to the same symbol, thereby reducing the conflict between the first and second versions (in the same generation In different versions of the code library, the parameters corresponding to the same symbol may be different. If the same symbol accesses different parameters, there will be a conflict). As a result, the code to be built can be compatible with the first version and the second version when running, because the dependency between the code to be built and the target split version is removed, and a link is configured between the code to be built and the target split version. Therefore, the compatibility between the first version and the second version can be achieved without affecting the original function of the code to be built. In this embodiment, no major modifications are required. It is only necessary to configure the link between the target split version and the code to be built and remove the dependency between the target split version and the code to be built, thereby improving the construction efficiency of the code to be built.

[0058] Based on this, the embodiment of the present application provides a code construction method, referring to Figure 1, Figure 1 This is a flowchart of the first embodiment of the code construction method of the present application. The code construction method includes steps S10 to S30:

[0059] Step S10: obtaining a first version and a second version of a first code base that the code to be built depends on, and if the first version and the second version are incompatible, determining a target split version between the first version and the second version;

[0060] It should be noted that the code to be built is represented by the code that currently needs to be built. In this embodiment, the code to be built can be the code of the intelligent driving perception module in the vehicle, for example, it can be the code of the Perception module, or it can be other codes that need to rely on different versions of the same library. This embodiment does not make specific limitations on this.

[0061] The first code base is a dynamic code base that the code to be built depends on. The first version and the second version are different versions of the same code base. For example, they can be different versions of the first code base. Generally, the first and second versions of the same code base are incompatible because different versions of the same library may have the same name, but the parameters of the same name are different in different versions, resulting in conflicts and errors during compilation or runtime.

[0062] The code to be built depends on versions 1 and 2 of the first code base, indicating that the code to be built requires the support of versions 1 and 2 to compile and run properly. Dependencies can be established through explicit declarations. For example, declaring a dependency on versions 1 and 2 in the code to be built only states what the dependency is, not how the dependency is implemented.

[0063] In this embodiment, there is at least one version whose dependency relationship is indirect between the first version and the second version that the code to be built depends on. For example, Figure 2 , the code to be built can directly depend on the first version, the code to be built depends on the second code base, and the second code base depends on the second version. In this case, the code to be built also needs to depend on the first version and the second version, but there is a second code base between the second version and the code to be built. In other embodiments, you can also refer to Figure 3 , the code to be built can also directly depend on the second version, the code to be built depends on the third code base, and the third code base depends on the first version. In other embodiments, please refer to Figure 4 The code to be built may also rely on a second code base, which in turn relies on the first version. The code to be built may also rely on a third code base, which in turn relies on the second version. This embodiment does not specifically limit this, and the specific implementation can be determined based on actual circumstances. The first code base, the second code base, and the third code base can all be dynamic code bases.

[0064] The target split version can be any one of the first version and the second version, which is not specifically limited in this embodiment. The target split version is a version that needs to remove dependencies from the code to be built.

[0065] For example, a first version and a second version of a first code base that the code to be built depends on are obtained. If the first version and the second version are incompatible, one of the first and second versions can be arbitrarily determined as the target split version. Furthermore, it should be noted that if the first and second versions of the first code base that the code to be built depends on are incompatible, and both the first and second versions need to run in the same process, the target split version can be determined between the first and second versions.

[0066] Step S20: configuring a link between the target split version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct to run local parameters when running the target split version;

[0067] It's important to note that linking indicates linking the target split version to the code to be built, so that when the code to be built needs parameters within the target split version, it can obtain them through the link. Linking differs from dependency. Dependency describes that the code to be built relies on the first and second versions, but it doesn't specify how the code to be built obtains the parameters within the first and second versions. Typically, the parameters within the first and second versions are obtained globally, which can easily lead to conflicts between the first and second versions. Linking describes how the code to be built obtains parameters within the target split version.

[0068] Include local isolation directives in the link. Local isolation directives can be used to instruct the target split version to call local parameters first.

[0069] Exemplarily, a link is configured between the target split version and the code to be built, so that when the code to be built is running, the target split version calls local parameters, thereby facilitating subsequent running of the code to be built and reducing conflicts between the first version and the second version.

[0070] Step S30 , compile the code to be built, and after the code to be built is compiled, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version during runtime.

[0071] It should be noted that compiling the code to be built can be used to check whether the syntax within the code to be built is correct, so that the code to be built can run normally. Before compiling the code to be built, the code to be built has no dependencies with the first and second versions. After compilation, the code to be built has dependencies with the first and second versions, respectively, thereby ensuring that the code to be built can compile normally and can compile the original functionality of the code to be built normally.

[0072] However, since the code to be built may not run normally due to the conflict between the first version and the second version at runtime, it is necessary to remove the dependency between the target split version and the code to be built. Because the link between the target split version and the code to be built is configured before removing the dependency between the target split version and the code to be built, the normal operation of the code to be built can be guaranteed while being compatible with the first version and the second version, without affecting the original function.

[0073] Exemplarily, after the code to be built is compiled, the dependency between the target split version and the code to be built is removed. For example, a preset dependency removal tool can be called to remove the dependency between the target split version and the code to be built. The preset dependency removal tool can be a patchelf tool (a modification tool) or other tools for removing dependencies. This embodiment does not specifically limit this.

[0074] When the first and second versions that the code to be built depends on are incompatible, the target split version can be determined in the first and second versions, and a link between the target split version and the code to be built can be configured so that the code to be built can obtain the parameters in the target split version through the link. At the same time, due to the presence of local isolation instructions in the link, the target split version calls local parameters when it is run, and does not call parameters of other versions in the same code base, which makes it easier for the first and second versions to be compatible when the code to be built is built later.

[0075] Furthermore, since the embodiment of the present application will compile the code to be built after configuring the link between the code to be built and the target split version to ensure the accuracy of the link configuration, the dependency between the target split version and the code to be built can be removed after the code to be built is compiled, so that the code to be built will not directly access the target split version when it is running, but will obtain the local parameters in the target split version through the link when the parameters in the target split version are needed, and will not obtain the parameters in the first version and the second version at the same time. Therefore, when the code to be built is running, the first version and the second version will not be accessed at the same time due to the same name, thereby reducing the conflict between the first version and the second version (in the same In different versions of the code library, the parameters corresponding to the same name may be different. If the same symbol accesses different parameters, there will be a conflict), so that the code to be built can be compatible with the first version and the second version when running, because the dependency between the code to be built and the target split version is removed, and a link is also configured between the code to be built and the target split version, so that the compatibility of the first version and the second version can be achieved without affecting the original function of the code to be built. In this embodiment, no major modifications are required. It is only necessary to configure the link between the target split version and the code to be built and remove the dependency between the target split version and the code to be built, thereby improving the construction efficiency of the code to be built.

[0076] In a feasible embodiment, the code construction method may further include steps A10 to A30:

[0077] Step A10: if a compilation error occurs in the code to be built, determine a target compilation isolation object;

[0078] It should be noted that when there is an error in the compilation of the code to be built, there may be a link configuration error, a syntax error in the code to be built, or the link cannot be implemented. At this time, a target compilation isolation object can be determined so that the compilation of the code to be built can be passed later.

[0079] For example, when a compilation error occurs in the code to be built, a target compilation isolation object can be determined in each code library that the code to be built depends on.

[0080] In a feasible embodiment, step A10 further includes steps A11 to A13:

[0081] Step A11: if an intermediate code library exists between the target split version and the code to be built, then the intermediate code library is determined as the target compilation isolation object, wherein the code to be built depends on the target split version through the intermediate code library;

[0082] It should be noted that the target split version can be the first version or the second version, and the dependency relationship between the first version and the code to be built, and the dependency relationship between the second version and the code to be built, can be direct or indirect. Different dependencies may not necessarily correspond to the same target compilation isolation object. Determining the target compilation isolation object facilitates the subsequent configuration of local compilation items for the target compilation isolation object, so that when the target compilation isolation object is compiled, local parameters are compiled instead of external parameters.

[0083] The intermediate code library is the code library between the target split version and the code to be built. The intermediate code library is not the first code. For example, when the target split version is the second version, the intermediate code library between the second version and the code to be built can be the second code library. When the target split version is the first version, the intermediate code library between the first version and the code to be built can be the third code library. This embodiment does not make specific restrictions on this. For example, you can refer to Figures 2 to 4 , Figures 2 to 4 The second code base shown in the figure is the intermediate code base between the second version and the code to be built, and the third code base is the intermediate code base between the first version and the code to be built. The package library does not belong to the intermediate code base.

[0084] When there is an intermediate code library between the target split version and the code to be built, it means that the code to be built depends on the intermediate code library, and the intermediate code library depends on the target split version. The code to be built depends on the target split version by relying on the intermediate code library, and the intermediate code library depends on the target split version. At this time, the target split version and the code to be built are indirectly dependent.

[0085] The intermediate code library can be an unpackaged code source, or a code source and a source code package library of the code source.

[0086] For example, when there is an intermediate code library between the target split version and the code to be built, when the intermediate code library is an unencapsulated code source code, the code to be built depends on the code source code, and the code source code depends on the target split version. At this time, if the code source code supports modification, the code source code can be used as the target compilation isolation object. If the code source code does not support modification, the source code encapsulation library of the code source code can be determined, and the source code encapsulation library can be used as the target compilation isolation object.

[0087] When the intermediate code library is the code source code and the source code encapsulation library, the code to be built depends on the source code encapsulation library, the source code encapsulation library depends on the code source, and the code source depends on the target split version. At this time, if the code source code supports modification, the code source code or the source code encapsulation library can be used as the target compilation isolation object. If the code source code does not support modification, the source code encapsulation library can be used as the target compilation isolation object.

[0088] Step A12: if there is a package library of the target split version between the target split version and the code to be built, determining the package library as the target compilation isolation object, wherein the code to be built depends on the target split version through the package library;

[0089] It should be noted that the encapsulation library is a encapsulation library of the target split version, and the encapsulation library can be used as a target compilation isolation object to configure local compilation items in the encapsulation library. When there is an encapsulation library of the target split version between the target split version and the code to be built, the code to be built depends on the encapsulation library, and the encapsulation library depends on the target split version. Generally, in order to reduce the modification of the code, the first version and the second version will not be modified directly. If the first version and the second version are modified, there may be a large number of modifications, and there are situations that are prone to errors. Therefore, in order to reduce the amount of modification, this embodiment can use the encapsulation library as a target compilation isolation object when there is an encapsulation library of the target split version between the target split version and the code to be built.

[0090] For example, if a package library of the target split version exists between the target split version and the code to be built, the package library can be determined as the target compilation isolation object. If both the package library of the target split version and the intermediate code library exist between the target split version and the code to be built, either the package library of the target split version or the intermediate code library can be used as the target compilation isolation object. This embodiment does not specifically limit this. It is understood that there can be multiple target compilation isolation objects, and local compilation items can be configured in each target compilation isolation object.

[0091] The package library is used as the target compilation isolation object, so that when the package library is compiled, the package library compiles local parameters. At the same time, the external visibility of the corresponding local parameters of the target compilation isolation object can be closed, thereby reducing the probability of conflict between the first version and the second version.

[0092] There is at least one indirect dependency between the first and second versions that the code to be built depends on. Therefore, if there is a direct dependency between the code to be built and the target split version, there is an indirect dependency between the code to be built and the target retained version, and the target retained version is different from the target split version. The target retained version is the version of the first and second versions that is not the target split version. The reason why there is at least one indirect dependency between the first and second versions that the code to be built depends on is that if the code to be built directly depends on the first and second versions, then the developer can directly adjust the code to be built so that the code to be built does not depend on different versions of the same code base at the same time. Indirect dependency means that there is an intermediate code base between the code to be built and the target split version, and direct dependency means that the code to be built directly depends on the target split version, or that the code to be built depends on the encapsulation library of the target split version, and the encapsulation library depends on the target split version.

[0093] In this embodiment, after the target compilation isolation object is determined, when the code to be built is compiled, the local parameters of at least one version of the first version and the second version that the code to be built depends on will not be viewed externally, thereby reducing the probability of conflict between the first version and the second version during the compilation stage, and making the code to be built compatible with the first version and the second version when running the code to be built.

[0094] For a better understanding of this embodiment, please refer to Figure 5 and Figure 6 , respectively give examples of the dependency relationship when the intermediate code library between the second version and the code to be built is the code source and the source code package library, and the dependency relationship when the package library exists between the first version and the code to be built. Figure 5 , the code to be built depends on the source code encapsulation library, the source code encapsulation library depends on the code source code, the code source code depends on the second version of the first code library, and the code library to be built depends on the first version of the first code library, wherein the code to be built can be Percption, the source code encapsulation library can be libbevfusion_core.so (core dynamic library), the code source code can be libspconv.so (sparse convolution dynamic library), the second version of the first code library can be libprotobuf.so (3.6) (Protocol Buffers dynamic library (version 3.6)), Protocol Buffers is a data serialization framework, and the second version of the first code library can be libprotobuf.so (3.12) (Protocol Buffers dynamic library (version 3.12)). Reference Figure 6 , Figure 6 The code to be built depends on the package library, and the package library depends on the first version of the first code library. Figure 5In the first code base, the second version can be the target split version, if Figure 5 If you need to determine the first version as the target split version, you need to determine the package library of the first version between the code to be built and the first version so that you can split the code to be built and the first version. For example, refer to Figure 6 As shown, in Figure 6 In the example, one of the first version and the second version can be arbitrarily determined as the target split version.

[0095] When there is an intermediate code library between the second version and the code to be built, and there is an encapsulation library of the second version, the code to be built depends on the intermediate code library, the intermediate code library depends on the encapsulation library of the second version, and the encapsulation library depends on the second version.

[0096] Step A20, configuring local compilation items for the target compilation isolation object, and compiling the target compilation isolation object;

[0097] Step A30: After the target compilation isolation object is compiled successfully, recompile the code to be built so that the code to be built is compiled successfully;

[0098] Among them, the local compilation item is used to instruct the target compilation isolation object to compile local parameters during compilation and close the external visibility permission to the local parameters of the target compilation isolation object.

[0099] It should be noted that configuring local compilation items for the target compilation isolation object can reduce the probability of conflicts between the first version and the second version. The local compilation item can be -Wl, -Bsymbolic (linker symbol binding option, function: force the dynamic library to give priority to the symbols defined by itself to avoid being overwritten by external symbols of the same name). -Wl, -Bsymbolic are used together to instruct the target compilation isolation object to compile local parameters during compilation, and turn off external visibility of the local parameters of the target compilation isolation object. Visible permissions are permissions to view the local parameters within the target split version. External refers to versions and code libraries other than the target compilation isolation object itself. When the external visibility of the target compilation isolation object is turned off, the local parameters of the target compilation isolation object will not be obtained when the external obtains the parameters through the global name, thereby avoiding conflicts between the first version and the second version.

[0100] Compile the target compilation isolation object, and after the target compilation isolation object is compiled and passed, recompile the code to be built, so as to facilitate the compilation of the code to be built. Compile the target compilation isolation object, so as to facilitate ensuring the accuracy of the syntax of the target compilation isolation object, so that the subsequent compilation of the code to be built can pass. If the compilation of the target compilation isolation object fails, the target compilation isolation object can be debugged to make the compilation of the target compilation isolation object pass. The environment for compiling the target compilation isolation object and the code to be built can be a CMake (cross-platform build tool) compilation environment, or other compilation environments such as Bazel (Google build tool), which is not specifically limited in this embodiment.

[0101] Exemplarily, the compilation file of the target compilation isolation object can be obtained, the local compilation item can be specified in the compilation file, and the target compilation isolation object can be compiled. After the target compilation isolation object is compiled successfully, the code to be built can be recompiled to ensure that the code to be built is compiled successfully.

[0102] This embodiment improves the compilation success rate of the code to be built by configuring the local compilation item of the target compilation isolation object when an error occurs in the compilation of the code to be built, thereby facilitating subsequent compatibility between the first version and the second version.

[0103] In a feasible embodiment, step A20 further includes steps A21 and A22:

[0104] Step A21, configuring the isolation name of the target compilation isolation object in the preset compilation file;

[0105] Step A22, compile the target compilation isolation object using a preset compilation file configured with the isolation name.

[0106] It should be noted that the preset compilation file represents the compilation file required when compiling the target compilation isolation object. When the compilation environment is the CMake compilation environment, the compilation file can be CMakelists.txt (the configuration file under CMake), and the isolation name is the name of the target compilation isolation object. The isolation name of the target compilation isolation object can be configured in the preset compilation file to declare the target compilation isolation object in the preset compilation file so that the target isolation object can be compiled.

[0107] For example, in the preset compilation file, TARGET_NAME is determined to be the isolation name of the target compilation isolate object, and TARGET_NAME needs to be placed after "add_library(${TARGET_NAME}...)", where TARGET_NAME is a variable in the preset compilation file. TARGET_NAME is used to store the isolation name of the target compilation isolate object. The target compilation isolate object is referenced through ${TARGET_NAME} in the add_library command. If the name of the target compilation isolate object needs to be modified, simply modify the isolation name stored in TARGET_NAME. When the target isolation object is needed later, you can directly reference TARGET_NAME, which facilitates more flexible compilation of the target compilation isolate object and improves flexibility.

[0108] For example, a preset variable is configured in a preset compilation file as the isolation name of the target compilation isolation object, and then the target compilation isolation object is compiled using the preset compilation file configured with the isolation name, thereby improving the flexibility of compilation. The preset variable may be TARGET_NAME.

[0109] In other embodiments, a compilation path may be specified, and the target compilation isolation object may be compiled through the compilation path. For example, if the target compilation isolation object exists in the specified compilation path, the target compilation isolation object may be compiled through the compilation path. If the target isolation object does not exist in the specified compilation path, the target isolation object may be copied to the compilation path so that the target compilation isolation object can be compiled normally. For example, the instruction corresponding to the specified compilation path may be:

[0110] set_target_properties(${TARGET_NAME}PROPERTIES INSTALL_RPATH"\${ORIGIN} / "); This instruction sets the runtime path of the target compiled isolate object. For example, the target compiled isolate object can be found from ${ORIGIN}, where ${ORIGIN} can be the directory where the target compiled isolate object is located.

[0111] In a feasible embodiment, step S20 further includes steps S21 to S23:

[0112] Step S21: If there is an intermediate code library between the target split version and the code to be built, and there is no encapsulation library of the target split version, configure a link to the target split version in the intermediate code library;

[0113] It should be noted that the link also includes a link identifier, which is used to represent the object to be linked. The link identifier of the configured link is different for different target split versions. For the same target split version, the link identifier of the configured link may also be different. For example, in the case where there is an intermediate code library between the target split version and the code to be built, if the intermediate code library is a modifiable code source code, then the link identifier can be configured in the code source code as a link to the target split version. If the intermediate code library includes an unmodifiable code source code, it is necessary to obtain the source code encapsulation library of the code source code, and configure the link identifier as the code source code in the source code encapsulation library, so that the source code encapsulation library can be linked to the code source code, and the code source code can depend on the target split version. Therefore, the link of the code source code is configured in the source code encapsulation library, and then the link between the target split version and the code to be built can be configured.

[0114] If the intermediate code library includes modifiable code source and source code package library, the link identifier configured in the code source can be a link to the target split version, or the link identifier configured in the source code package library can be a link to the code source.

[0115] For example, the intermediate code library may be libspconv.so, and the intermediate code library may also be libspconv.so and libbevfusion_core.so, wherein libspconv.so is the code source code, and libbevfusion_core.so is the source code encapsulation library of the code source code.

[0116] In addition, it should be noted that the link also includes lazy loading instructions and visible instructions. The lazy loading instruction is characterized by loading the object corresponding to the link identifier when it is needed, thereby avoiding errors in the initialization of the code to be built. For example, when the link identifier is the target split version, the object corresponding to the link identifier is the target split version, and when the link identifier is the code source code, the object corresponding to the link identifier is the code source code. The visible instruction indicates that the library loaded subsequently can use the symbols in the object corresponding to the link identifier, thereby facilitating cross-library use and ensuring the normal operation of the code to be built. Since the link between the code to be built and the target split version is removed, the code to be built will not access the parameters in the target split version when calling the parameters of the target retained version, thereby avoiding conflicts between the target retained version and the target split version.

[0117] Exemplarily, when there is an intermediate code library between the target split version and the code to be built, and there is no encapsulation library of the target split version, if the intermediate code library is a modifiable code source code, then the link identifier can be configured in the code source code as a link to the target split version. If the intermediate code library includes an unmodifiable code source code, it is necessary to obtain the source code encapsulation library of the code source code, and configure the link identifier as a link to the code source code in the source code encapsulation library. If the intermediate code library includes modifiable code source code and source code encapsulation library, then the link identifier configured in the code source code can be a link to the target split version, or the link identifier can be configured in the source code encapsulation library as a link to the code source code. The target split version can be the first version or the second version. When the target split version is the first version, the identifier of the target split version is the identifier of the first version. When the identifier of the target split version is the second version, the identifier of the target split version is the identifier of the second version.

[0118] For example, a link can be expressed in the form of an instruction. For example, when the link is configured in a source code package library, the link can be expressed as:

[0119] static__attribute__((constructor))void_init_bev(void){

[0120] dlopen("libspconv.so",RTLD_LAZY|RTLD_DEEPBIND|RTLD_GLOBAL)};

[0121] libspconv.so is the identifier of the source code, RTLD_LAZY is the lazy load instruction, RTLD_DEEPBIND is the local isolation instruction, and RTLD_GLOBA is the visible instruction. static__attribute__((constructor))void_init_bev(void) declares the function required for executing dlopen, which is a loading function.

[0122] Step S22: If there is a package library between the code to be built and the target split version, and no intermediate code library exists, configure a link to the target split version in the package library;

[0123] Step S23 : if there is an encapsulation library and an intermediate code library between the code to be built and the target split version, then a link to the target split version is configured in the encapsulation library, or a link to the target split version is configured in the intermediate code library.

[0124] It should be noted that when configuring the link of the target split version in the package library, the link identifier of the link can be the identifier of the target split version. When there is a package library between the code to be built and the target split version, the link of the target split version can be configured in the package library. Since the dependency between the code to be built and the package library will not be disconnected, configuring the link of the target split version in the package library can also realize the configuration of the link between the code to be built and the target split version.

[0125] If there is both an intermediate code library and a footprint library for the target split version between the code to be built and the target split version, configure the link to the target split version in the footprint library or in the intermediate code library. This increases the flexibility of the link configuration.

[0126] Exemplarily, when there is a package library between the code to be built and the target split version, and no intermediate code library exists, a link with a link identifier of the target split version is configured in the package library; when there is a package library and an intermediate code library between the code to be built and the target split version, a link with a link identifier of the target split version is configured in the package library, a link with a link identifier of the target split version is configured in the modifiable code source code in the intermediate code library, or a link with a link identifier of the code source code is configured in the source code package library in the intermediate code library. This embodiment configures a link between the code to be built and the target split version, thereby facilitating access to the target split version through the link after the dependency between the code to be built and the target split version is subsequently removed, while preventing conflicts between different versions of the same code library, thereby facilitating improved code building efficiency.

[0127] In a feasible embodiment, step S30 further includes steps S31 and S32:

[0128] Step S31, in the case of a package library linked between the target split version and the code to be built, calling a preset dependency removal tool to remove the dependency between the package library and the target split version, so as to remove the dependency between the target split version and the code to be built;

[0129] It's important to note that you can call a pre-set dependency removal tool to remove the dependency between the code to be built and the target split version. When the link is configured in the package library of the target split version, the dependency between the package library and the target split version can be removed, thereby removing the dependency between the target split version and the code to be built. Because the package library is linked to the target split version, the code to be built can obtain local parameters within the target split version through the link when it runs, thus ensuring the normal operation of the code.

[0130] Exemplarily, when the target split version is the first version and the encapsulation library is linked and configured between the first version and the code to be built, the dependency between the encapsulation library and the first version is removed to remove the dependency between the target split version and the code to be built; when the target split version is the second version and the encapsulation library is linked and configured between the second version and the code to be built, the dependency between the encapsulation library and the second version is removed to remove the dependency between the target split version and the code to be built.

[0131] Step S32: In the case of an intermediate code library linked between the target split version and the code to be built, a preset dependency removal tool is called to remove the dependency between the intermediate code library and the target split version, so as to remove the dependency between the target split version and the code to be built.

[0132] It should be noted that a wrapper library is a wrapper library for the target split version, while a source wrapper library is a wrapper library for the source code. When an intermediate code library is linked between the target split version and the code to be built, the dependency between the intermediate code library and the target split version can be removed, thereby removing the dependency between the target split version and the code to be built.

[0133] Specifically, when the link is configured within the modifiable source code of the intermediate code library between the target split version and the code to be built, the dependency between the source code and the target split version can be removed. When the link is configured within the source code encapsulation library of the intermediate code library between the target split version and the code to be built, the dependency between the source code encapsulation library and the target split version can be removed. This removes the dependency between the target split version and the code to be built.

[0134] For example, the preset dependency removal tool can be a patchelf tool. The patchelf tool can be called and a preset removal command can be used to remove the dependency between the target split version and the code to be built. The preset removal command and the preset dependency removal tool can be used together to remove the dependency between the target split version and the code to be built. For example, when it is necessary to remove the dependency between the source code encapsulation library and the code source code, the source code encapsulation library is libbevfusion_core.so, and the code source code is libperception.so, the preset removal command can be: patchelf --remove-needed libbevfusion_core.so libperception.so; this command indicates that the dependency on the code source code libperception.so is removed from the source code encapsulation library libbevfusion_core.so. Other commands that can remove dependencies may also be used, and this embodiment does not specifically limit this.

[0135] Exemplarily, when the target split version is the first version and the link is configured in the modifiable code source of the intermediate code library between the first version and the code to be built, the preset dependency removal tool can be called to remove the dependency between the code source and the first version. When the target split version is the first version and the link is configured in the source code encapsulation library of the intermediate code library between the first version and the code to be built, the preset dependency removal tool can be called to remove the dependency between the source code encapsulation library and the code source.

[0136] When the target split version is the second version and the link is configured in the modifiable code source of the intermediate code library between the second version and the code to be built, the preset dependency removal tool can be called to remove the dependency between the code source and the second version. When the target split version is the second version and the link is configured in the source code encapsulation library of the intermediate code library between the second version and the code to be built, the preset dependency removal tool can be called to remove the dependency between the source code encapsulation library and the code source.

[0137] This embodiment removes the dependency between the target split version and the code to be built based on the location of the link configuration, thereby removing the dependency between the code to be built and the target version without affecting the original functionality of the code to be built, so that the subsequent code to be built can be compatible with the first version and the second version.

[0138] In a feasible embodiment, after step S30, the method further includes step X10: running the code to be constructed;

[0139] Among them, during the running process of the code to be built, the code to be built supports direct access to the target retained version to call the local parameters of the target retained version. When the code to be built needs to call the local parameters of the target split version, the local parameters of the target split version are called through the link; the target retained version is the version of the first version and the second version without removing the dependency.

[0140] It should be noted that after removing the dependency between the target split version and the code to be built, the code to be built can be run. When the code to be built is running, it will directly access the parameters in the target retained version. Since the dependency between the code to be built and the target split version has been removed, the code to be built will not directly access the target split version, but will call the local parameters of the target split version through linking. Therefore, the first version and the second version of the code to be built will not conflict when the code is running.

[0141] For example, when the source code encapsulation library of the intermediate code library is linked and configured between the target split version and the code to be built, when the code to be built is running, the code to be built will call the local parameters of the target retained version and will not directly call the parameters of the target split version. When the code to be built needs to use the local parameters of the target split version, the local parameters of the target split version will be called through the source code encapsulation library, thereby achieving compatibility between the first version and the second version. The compatibility between the first version and the second version is achieved with minor changes, which improves the efficiency of the construction of the code to be built and, at the same time, facilitates improving the running efficiency of the code to be built.

[0142] If you do not configure the link and remove the dependency on one version, errors may occur during initialization or compilation of the code to be built. For example, when the code to be built is initially loaded, the objects that the code to be built depends on will be parsed in sequence before the main function in the code to be built. If two incompatible versions exist, this will cause an error in the main function parsing. For example, if the code to be built depends on a source code package library, the source code package library depends on the source code, the source code depends on the first version, and the code to be built depends on the second version, the main function will parse the source code package library, the source code, and the first version in sequence, and will also parse the second version. However, the first and second versions are incompatible, which will cause an error.

[0143] In this embodiment, the dependency between the target segmented version and the code to be built is removed. Therefore, when the code to be built is initially loaded, it will not be parsed to the first version and the second version at the same time, and thus there will be no loading errors. Since a link is configured between the code to be built and the target segmented version, it is easy to ensure the normal operation of the code to be built. This embodiment can achieve compatibility of different versions of the same code base without changing the main structure of the code to be built or the main structure of different versions of the first code base, thereby improving the efficiency of the construction, and there is no need to use dlsym (dynamic symbol lookup function) to encapsulate a large number of API (Application Programming Interface) functions to be compatible with different versions, thereby reducing the complexity of compatibility. This embodiment can be applicable to scenarios where the code to be built needs to rely on different versions of the same code base.

[0144] The present application also provides a code construction device, please refer to Figure 7 , the device comprises:

[0145] An acquisition module 10 is configured to acquire a first version and a second version of a first code library that the code to be built depends on, and if the first version and the second version are incompatible, determine a target split version between the first version and the second version;

[0146] A configuration module 20 is configured to configure a link between the target segmented version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target segmented version to call local parameters when running;

[0147] The compatibility module 30 is used to compile the code to be built, and after the code to be built is compiled, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

[0148] The configuration module 20 is further configured to determine a target compilation isolation object when an error occurs in the compilation of the code to be constructed;

[0149] Configuring local compilation items for the target compilation isolation object and compiling the target compilation isolation object;

[0150] After the target compilation isolation object is compiled successfully, recompile the code to be built so that the code to be built is compiled successfully;

[0151] The local compilation item is used to instruct the target compilation isolation object to compile local parameters during compilation, and to close external visibility permissions to the local parameters of the target compilation isolation object.

[0152] The configuration module 20 is further configured to determine, if an intermediate code library exists between the target segmented version and the code to be built, that the intermediate code library is a target compilation isolation object, wherein the code to be built depends on the target segmented version through the intermediate code library;

[0153] In a case where a package library of the target split version exists between the target split version and the code to be built, the package library is determined to be a target compilation isolation object, wherein the code to be built depends on the target split version through the package library.

[0154] The configuration module 20 is further configured to configure the isolation name of the target compilation isolation object in a preset compilation file;

[0155] The target compilation isolation object is compiled by configuring a preset compilation file with the isolation name.

[0156] The configuration module 20 is further configured to configure a link to the target split version in the intermediate code library when there is an intermediate code library between the target split version and the code to be built and there is no encapsulation library of the target split version;

[0157] In a case where there is an encapsulation library between the code to be built and the target split version and no intermediate code library exists, configuring a link to the target split version in the encapsulation library;

[0158] In the case that a package library and an intermediate code library exist between the code to be built and the target split version, a link to the target split version is configured in the package library, or a link to the target split version is configured in the intermediate code library.

[0159] The compatibility module 30 is further configured to, when the link is configured in the encapsulation library between the target split version and the code to be built, call a preset dependency removal tool to remove the dependency between the encapsulation library and the target split version, so as to remove the dependency between the target split version and the code to be built;

[0160] In the case where the link is configured as an intermediate code library between the target split version and the code to be built, a preset dependency removal tool is called to remove the dependency between the intermediate code library and the target split version, so as to remove the dependency between the target split version and the code to be built.

[0161] The compatible module 30 is further used to run the code to be constructed;

[0162] During the execution of the code to be built, the code to be built supports direct access to the target retained version to call the local parameters of the target retained version. When the code to be built needs to call the local parameters of the target split version, the code to be built calls the local parameters of the target split version through the link; the target retained version is the version of the first version and the second version from which the dependency has not been removed.

[0163] The code construction device provided in the embodiments of the present application adopts the code construction method in the above embodiments, aiming to solve the technical problem of low code construction efficiency when the code needs to rely on different versions of code libraries. Compared with the prior art, the beneficial effects of the code construction method provided in the embodiments of the present application are the same as those of the code construction method provided in the above embodiments, and the other technical features of the code construction device are the same as those disclosed in the above embodiments, and are not further described here.

[0164] The present application provides an electronic device, which includes: at least one processor, and a memory connected to the at least one processor, wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute to implement the code construction method of the above embodiment. Figure 8, which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present application. The electronic devices in the embodiments of the present application may include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0165] like Figure 8As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems may be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape or a hard disk; and a communication device 1009. The communication device 1009 may allow the electronic device to communicate with other devices wirelessly or wired to exchange data. Although the figures show electronic devices with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or provided instead. In particular, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above functions defined in the method of the embodiment disclosed in this application are executed. The electronic device provided in this application adopts the code construction method in the above embodiment to solve the technical problem of low code construction efficiency when the code needs to rely on different versions of the code library. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the code construction method provided in the above embodiment, and the other technical features in the electronic device are the same as those disclosed in the method of the previous embodiment, which will not be repeated here.

[0166] It should be understood that the various parts disclosed in this application can be implemented with hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples. The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims. This embodiment provides a computer-readable storage medium having computer-readable program instructions stored thereon, and the computer-readable program instructions are used to execute the code construction method in the above embodiment one. The computer-readable storage medium provided in the embodiment of this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, equipment or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), an erasable programmable EPROM (Electrical Programmable Read Only Memory) or flash memory, optical fiber, a portable compact disk CD-ROM (compact disc read-only memory), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution device, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof. The above-mentioned computer-readable storage medium may be contained in an electronic device; or it may exist separately without being incorporated into the electronic device. The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by an electronic device, the electronic device: obtains the first version and the second version of the first code library that the code to be built depends on, and when the first version and the second version are incompatible, determines the target split version in the first version and the second version; configures a link between the target split version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target split version to call local parameters when running; compiles the code to be built, and after the compilation of the code to be built is passed, removes the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

[0167] The computer program code for performing the operation of the present disclosure can be written in one or more programming languages ​​or a combination thereof, and the above-mentioned programming languages ​​include object-oriented programming languages ​​- such as Java, Smalltalk, C++, and also include conventional procedural programming languages ​​- such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network - including LAN (local area network) or WAN (Wide Area Network, wide area network), or it can be connected to an external computer (for example, using an Internet service provider to connect through the Internet). The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the equipment, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of the code, and the module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the accompanying figures. For example, two blocks shown in succession may actually be executed substantially in parallel, or they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flow charts, and combinations of blocks in the block diagrams and / or flow charts, may be implemented using dedicated hardware-based devices that perform the specified functions or operations, or may be implemented using a combination of dedicated hardware and computer instructions.

[0168] The modules involved in the embodiments described in the present disclosure can be implemented by software or by hardware. Wherein, the name of the module does not constitute a limitation of the unit itself under certain circumstances. The computer-readable storage medium provided in the embodiment of the present application stores computer-readable program instructions for executing the above-mentioned code construction method, which is intended to solve the technical problem of low code construction efficiency when the code needs to rely on different versions of the code library. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the embodiment of the present application are the same as the beneficial effects of the code construction method provided in the above-mentioned embodiment, and are not described in detail here. The embodiment of the present application also provides a computer program product, including a computer program, which implements the steps of the code construction method as described above when the computer program is executed by a processor. The computer program product provided in the embodiment of the present application is intended to solve the technical problem of low code construction efficiency when the code needs to rely on different versions of the code library. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiment of the present application are the same as the beneficial effects of the code construction method provided in the above-mentioned embodiment, and are not described in detail here. The above are only preferred embodiments of the embodiments of the present application, and do not limit the patent scope of the embodiments of the present application. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of the embodiments of the present application, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the embodiments of the present application.

Claims

1. A code construction method, characterized in that: The method includes: Obtaining a first version and a second version of a first code library that the code to be built depends on, and if the first version and the second version are incompatible, determining a target split version between the first version and the second version; Configuring a link between the target split version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target split version to call local parameters when running; Compile the code to be built, and after the code to be built is compiled successfully, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

2. The code construction method according to claim 1, wherein: The method further comprises: In the event that a compilation error occurs in the code to be built, determining a target compilation isolation object; Configuring local compilation items for the target compilation isolation object and compiling the target compilation isolation object; After the target compilation isolation object is compiled successfully, recompile the code to be built so that the code to be built is compiled successfully; The local compilation item is used to instruct the target compilation isolation object to compile local parameters during compilation, and to close external visibility permissions to the local parameters of the target compilation isolation object.

3. The code construction method according to claim 2, wherein: The step of determining the target compilation isolation object includes: If an intermediate code library exists between the target segmented version and the code to be built, determining the intermediate code library as a target compilation isolation object, wherein the code to be built depends on the target segmented version through the intermediate code library; In a case where a package library of the target split version exists between the target split version and the code to be built, the package library is determined to be a target compilation isolation object, wherein the code to be built depends on the target split version through the package library.

4. The code construction method according to claim 2, wherein: The step of compiling the target compile isolation object comprises: Configure the isolation name of the target compilation isolation object in the preset compilation file; The target compilation isolation object is compiled by configuring a preset compilation file with the isolation name.

5. The code construction method according to claim 1, wherein: The step of configuring the link between the target split version and the code to be built includes: In a case where an intermediate code library exists between the target segmented version and the code to be built, and no encapsulation library of the target segmented version exists, configuring a link to the target segmented version in the intermediate code library; In a case where there is an encapsulation library between the code to be built and the target split version and no intermediate code library exists, configuring a link to the target split version in the encapsulation library; In the case that a package library and an intermediate code library exist between the code to be built and the target split version, a link to the target split version is configured in the package library, or a link to the target split version is configured in the intermediate code library.

6. The code construction method according to claim 1, wherein: The step of removing the dependency between the target split version and the code to be built includes: In the case where the link is configured as a package library between the target split version and the code to be built, calling a preset dependency removal tool to remove the dependency between the package library and the target split version, so as to remove the dependency between the target split version and the code to be built; In the case where the link is configured as an intermediate code library between the target split version and the code to be built, a preset dependency removal tool is called to remove the dependency between the intermediate code library and the target split version, so as to remove the dependency between the target split version and the code to be built.

7. The code construction method according to claim 1, wherein: After the step of removing the dependency between the target split version and the code to be built, the method further includes: Run the code to be built; During the execution of the code to be built, the code to be built supports direct access to the target retained version to call the local parameters of the target retained version. When the code to be built needs to call the local parameters of the target split version, the code to be built calls the local parameters of the target split version through the link; the target retained version is the version of the first version and the second version from which the dependency has not been removed.

8. A code construction device, characterized in that: The device comprises: an acquisition module, configured to acquire a first version and a second version of a first code library on which the code to be built depends, and if the first version and the second version are incompatible, determine a target split version between the first version and the second version; a configuration module, configured to configure a link between the target segmented version and the code to be built, wherein the link includes a local isolation instruction, and the local isolation instruction is used to instruct the target segmented version to call local parameters when running; The compatibility module is used to compile the code to be built, and after the code to be built is compiled, remove the dependency between the target split version and the code to be built, so that the code to be built is compatible with the first version and the second version when running.

9. An electronic device, characterized in that: The electronic device includes at least one processor, and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute to implement the steps of the code construction method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, on which a program for implementing the code construction method is stored. The program for implementing the code construction method is executed by a processor to implement the steps of the code construction method according to any one of claims 1 to 7.

Images