Method, device and system for locally deploying cross-platform graph database program

Abstract

The invention relates to a method, a device and a system for locally deploying a cross-platform graph database program. The method mainly comprises the steps that a vcpkg package manager is deployed, and a vcpkg.json file is created under a directory where a program is located; creating CMakeLists.txt in a catalog where the program is located for defining how to construct the program and linking a third-party library installed through the vcpkg; an executable file of the database is generated by running the CMake command; recursively collecting all third-party libraries on which the program depends through an ldd command and an awk command, and copying all the third-party libraries on which the program depends and an ld interpreter of the program to a directory where the program is located; through the patchelf file, modifying an ld interpreter path of the program to be a relative path under a catalog where the program is located, and modifying a rpath of the program to be the relative path under the catalog where the program is located; and packaging and delivering the files in the catalog where the program is located to a user. According to the method, a developer can construct a database program deployed in a zero-dependence manner.

Description

Technical Field

[0001] The present invention relates to the field of computer program technology, and in particular to a method, device and system for locally deploying a cross-platform graph database program. Background Art

[0002] A graph database is a non-relational database that mainly stores entities and the relationships between entities. Because it can store the unique relational value of graph models, the market demand for graph databases is increasing, and distributed graph databases have emerged. In order to achieve high availability, distributed graph databases need to be able to be quickly deployed on multiple machines, especially in the case of sudden failures, and need to be able to run directly on the user's newly added machines to achieve fast failover. These machines may have different architectures and operating systems (the types are relatively limited), especially different C / C++ runtime libraries (there are many types, such as different versions of Linux distributions may have different C / C++ runtime libraries), which poses a challenge to the quick deployment of databases.

[0003] At present, mainstream database vendors usually prepare development machines with multiple architectures and multiple operating systems (each system will pre-install a certain version of C / C++ runtime library) during the development stage, and compile their corresponding database programs on these machines. For example, prepare an x86 machine with CentOS7 operating system installed and GNU Compiler Collection (GCC) version 4.7. In principle, the program compiled by this machine can only be run on the user machine with the same software environment. Otherwise, some runtime dependency libraries (such as C / C++ runtime library and other third-party libraries) may need to be manually installed in the user environment, and sometimes the installation may fail due to network isolation or permission issues. The above solution cannot really meet the needs of all user machine software environments to run database programs once and for all. When a user uses an environment that the vendor has not prepared during the development process, the user needs to wait for the vendor to prepare the corresponding development environment to compile the corresponding program version, which greatly increases the development cost of database developers, reduces development efficiency, and reduces the service quality of user software, delaying business decisions.

[0004] In view of this, how to overcome the defects of the existing technology and how to meet the needs of quickly deploying database programs in different software environments without manually installing third-party libraries on the user's machine has become an important technical problem that needs to be urgently solved in the industry. Summary of the invention

[0005] In view of the defects or improvement needs in the prior art: how to meet the requirements of rapid deployment of database programs in different software environments without manually installing third-party libraries on the user's machine. The present invention provides a method, device and system for locally deploying cross-platform graph database programs. Through the innovative combination of vcpkg, CMake, ldd, patchelf and other technologies, developers can build zero-dependency deployed database programs; during the development process, developers do not need to manually install third-party dependency libraries, thereby reducing development costs and improving program building efficiency. More importantly, during the deployment process, you do not need to worry about the user's software environment, and you can deploy a distributed graph database program without installing dependency libraries in the user's local environment, so that the program can be compiled once and run in multiple places, greatly improving the work efficiency of database developers and implementers, and also improving the availability of user database services.

[0006] The present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for locally deploying a cross-platform graph database program, comprising:

[0008] Deploy the vcpkg package manager and create a vcpkg.json file in the directory where the program is located. The vcpkg.json file includes the name and version number of the third-party library that the program depends on;

[0009] Create CMakeLists.txt in the program directory to define how to build the program and link the third-party library installed by vcpkg; generate the executable file of the database by running the CMake command;

[0010] Use the ldd command and awk command to recursively collect all third-party libraries that the program depends on, and copy all third-party libraries that the program depends on and the program's ld interpreter to the directory where the program is located;

[0011] Through the patchelf file, modify the program's ld interpreter path to the relative path under the program's directory, and modify the program's rpath to the relative path under the program's directory;

[0012] Package the files in the directory where the program is located and deliver them to the user. After deployment, the user can directly run the executable file to automatically install all third-party libraries that the program depends on.

[0013] In some embodiments, deploying the vcpkg package manager specifically includes:

[0014] Deploy the vcpkg package manager in the development CI environment of the database developer to configure the third-party libraries that the installer depends on according to the vcpkg.json file provided by the project.

[0015] In some embodiments, the name and version number of the third-party library that the program depends on are defined in the vcpkg package manager.

[0016] In some embodiments, the definition of how to construct a program specifically includes: defining source code included in the program and the compile options and link options used.

[0017] In some embodiments, the executable file of the database generated by running the CMake command specifically includes:

[0018] Run CMake by specifying the CMake tool script path that comes with the vcpkg package manager;

[0019] The CMake tool script automatically installs the dependent third-party libraries according to the vcpkg.json file in the current directory, and automatically sets the dependent third-party library path to the path that CMake can find;

[0020] The CMake program uses the CMakeLists.txt in the current directory to build the database executable file.

[0021] In some embodiments, the ldd command is used to output which third-party libraries the program depends on and the locations of the dependent third-party library files.

[0022] In some embodiments, after all third-party libraries that the program depends on and the ld interpreter of the program are copied to the directory where the program is located, the copied ld interpreter is granted executable permission.

[0023] In a second aspect, the present invention further provides a device for locally deploying a cross-platform graph database program, the device comprising:

[0024] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the method for locally deploying a cross-platform graph database program as described in the first aspect.

[0025] In a third aspect, the present invention further provides a system for locally deploying a cross-platform graph database program, applying the method for locally deploying a cross-platform graph database program as described in the first aspect, the system comprising a vcpkg creation module, a CMake creation module, an ldd command module, a path modification module, and a packaging and sending module, wherein:

[0026] The vcpkg creation module is used to: deploy the vcpkg package manager and create a vcpkg.json file in the directory where the program is located. The vcpkg.json file includes the name and version number of the third-party library that the program depends on;

[0027] The CMake creation module is used to: create CMakeLists.txt in the directory where the program is located, which is used to define how to build the program and link the third-party library installed by vcpkg; generate an executable file of the database by running the CMake command;

[0028] The ldd command module is used to: recursively collect all third-party libraries that the program depends on through the ldd command and the awk command, and copy all third-party libraries that the program depends on and the ld interpreter of the program to the directory where the program is located;

[0029] The path modification module is used to: modify the ld interpreter path of the program to a relative path under the directory where the program is located, and modify the rpath of the program to a relative path under the directory where the program is located through the patchelf file;

[0030] The packaging and sending module is used to package the files in the directory where the program is located and deliver them to the user, so that after the user deploys the program, he can directly run the executable file to automatically install all the third-party libraries that the program depends on.

[0031] In a fourth aspect, the present invention further provides a non-volatile computer storage medium storing computer executable instructions, which are executed by one or more processors to complete the method of locally deploying a cross-platform graph database program as described in the first aspect.

[0032] Compared with the prior art, the present invention provides a method, device and system for locally deploying cross-platform graph database programs, which has the following beneficial effects: through the innovative combination of vcpkg, CMake, ldd, patchelf and other technologies, developers can build zero-dependency deployment database programs; during the development process, developers do not need to manually install third-party dependency libraries, thereby reducing development costs and improving program building efficiency. More importantly, during the deployment process, you do not need to care about the user's software environment, and you can deploy distributed graph database programs without installing dependency libraries in the user's local environment, so that the program can be compiled once and run in multiple places, greatly improving the work efficiency of database developers and implementers, and also improving the availability of user database services. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required to be used in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0034] Figure 1 A flowchart of a method for locally deploying a cross-platform graph database program provided in Example 1 of the present invention;

[0035] Figure 2 A schematic diagram of a system module for locally deploying a cross-platform graph database program provided in Example 1 of the present invention;

[0036] Figure 3 A schematic diagram of a traditional third-party library compilation and installation process provided in Example 2 of the present invention;

[0037] Figure 4 A schematic diagram of the process of compiling and installing a third-party library using the vcpkg technology provided in Example 2 of the present invention;

[0038] Figure 5 A schematic diagram of a mechanism for searching for dependencies during program execution under normal circumstances provided in Embodiment 2 of the present invention;

[0039] Figure 6 A schematic diagram of a mechanism for searching for dependencies during runtime after patchelf modifies an executable file provided in Embodiment 2 of the present invention;

[0040] Figure 7 A schematic diagram of a complete process of using multiple technologies to efficiently compile and deploy zero-dependency programs provided in Example 2 of the present invention;

[0041] Figure 8 A schematic diagram of the structure of a device for locally deploying a cross-platform graph database program provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0042] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, without departing from the concept of the present invention, several variations and improvements can also be made. These all belong to the protection scope of the present invention. It should be noted that, if there is no conflict, the various features in the embodiments of the present invention can be combined with each other, all within the protection scope of this application. In addition, although the functional module division may be performed in the device schematic diagram, and the logical order may be shown in the flow chart, in some cases, it may be different from the module division in the device, or the steps shown or described in the order in the flow chart may be performed.

[0043] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in this specification and in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. In addition, the technical features involved in each embodiment of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0044] Unless the context requires otherwise, throughout the specification and claims, the term "including" is to be interpreted as open inclusion, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" and the like are intended to indicate that specific features, structures, materials or characteristics associated with the embodiment or example are included in at least one embodiment or example of the present disclosure. The schematic representation of the above terms does not necessarily refer to the same embodiment or example. In addition, the specific features, structures, materials or characteristics may be included in any one or more embodiments or examples in any appropriate manner, that is, although they may be carried in the embodiments or examples of the above terms due to reasons such as the order and position of appearance, it is not limited to that they can be carried in combination by one embodiment or example.

[0045] In order to make the purpose, technical scheme and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0046] Embodiment 1:

[0047] like Figure 1 As shown, an embodiment of the present invention provides a method for locally deploying a cross-platform graph database program, which includes the following steps.

[0048] Step 101: Deploy the vcpkg package manager and create a vcpkg.json file in the directory where the program is located. The vcpkg.json file includes the name and version number of the third-party library that the program depends on. In this step, write the vcpkg configuration according to the third-party library required by the program, which is used to automatically download and install the third-party library through the vcpkg package manager. The written vcpkg configuration needs to specify a stable package manager baseline and explicitly specify the version number of the third-party library. It should be noted that vcpkg is a free and open source C / C++ package manager.

[0049] Step 102: Create CMakeLists.txt in the directory where the program is located, which is used to define how to build the program and link the third-party library installed by vcpkg; generate the executable file of the database by running the CMake command. In this step, a CMake script is written for the project to define the program source code list and the compilation process of the program, and generate an ELF format database executable file. ELF stands for Executable and Linkable Forma, which is a file format used for executable files, target files, and libraries. The CMake script needs to be able to support multiple operating systems and be able to use third-party dependent libraries installed by vcpkg. At the same time, the CMake script needs to support the construction of multiple program versions, such as supporting the construction of Debug version, Release version, and Release version with symbols. In this embodiment, the directory where the executable file is located is also the directory where the program is located.

[0050] Step 103: recursively collect all third-party libraries that the program depends on through the ldd command and the awk command, and copy all third-party libraries that the program depends on and the ld interpreter of the program to the directory where the program is located. In this step, the ldd command is used to output which third-party libraries the program depends on and the location of the third-party library files that it depends on; write a shell script, and copy the dependent library files of the database executable file to the directory where the program is located through the ldd command and the awk command. These dependent library files will eventually be released with the database executable file. The packaging script needs to be able to copy all the dependencies of the program (this also includes the dependencies of the dependencies) to the directory where the database executable file is located, that is, to achieve recursive dependency copying, and some dynamic libraries need to have executable file permissions, otherwise the program may not run correctly; this is particularly critical. Therefore, after all third-party libraries that the program depends on and the ld interpreter of the program are copied to the directory where the program is located, the copied ld interpreter is given executable permissions.

[0051] It should be noted that for the ld interpreter, the ELF file of the executable file always has a section called the program header table. This section provides the information required to run the executable file. One of the important entries in the program header table when running an executable file is the PT_INTERP entry; this entry specifies the runtime or dynamic linker (or ld interpreter) required to assemble the complete program before running, usually named ld-linux.so. In other words: when the operating system runs a program, it actually "loads" the ld dynamic linker that runs the program first, and the latter handles other things required for the program to run. For example: 1. Find the necessary shared libraries; 2. Load the shared libraries into memory; 3. Use the symbols in the shared libraries to resolve the program's undefined symbols; 4. Assemble the program so that the process can call the functions in the shared libraries at runtime. In other words, the interpreter specified by the PT_INTERP entry in the program header table manages the shared libraries that the executable file depends on at runtime.

[0052] Step 104: Use the patchelf file to modify the ld interpreter path of the program to the relative path under the directory where the program is located, and modify the rpath of the program to the relative path under the directory where the program is located. In this step, write a script to modify the database executable file, and use this script to modify some internal properties of the database executable file, so that the modified program does not need to search for dependencies from the system directory, but searches for dependencies from the directory where the database executable file is located. The patchelf program needs to correctly modify the database executable file, and cannot cause the problem of being unable to execute the executable file, nor can it affect the correctness of the program when it is running; this is particularly critical.

[0053] It should be noted that rpath is an optional attribute in the executable file and is empty by default. Its value represents a path, which is used to instruct the operating system to load dependent libraries from the path pointed to by rpath when running the program. Usually, the executable file compiled by default does not contain rpath.

[0054] Step 105: Package the files in the directory where the program is located and deliver them to the user, so that after deployment, the user can directly run the executable file to automatically install all third-party libraries that the program depends on.

[0055] Based on the above steps, this embodiment allows developers to build a zero-dependency deployment database program through an innovative combination of vcpkg, CMake, ldd, patchelf and other technologies; during the development process, developers do not need to manually install third-party dependency libraries, thereby reducing development costs and improving program building efficiency. More importantly, during the deployment process, you do not need to worry about the user's software environment, and you can deploy a distributed graph database program without installing dependency libraries in the user's local environment, so that the program can be compiled once and run in multiple places, greatly improving the work efficiency of database developers and implementers, and also improving the availability of user database services.

[0056] The principle of the solution adopted in this embodiment is described in detail below.

[0057] In some embodiments, the vcpkg package manager needs to be deployed in the development CI environment of the database developer first. It is used to configure the third-party dependency library of the installation program according to the vcpkg.json provided by the project, that is, the third-party library that the program depends on.

[0058] In some embodiments, vcpkg.json is created in the root directory of the database program project, which includes the name of the third-party library that the program directly depends on and its version number. Note that the program name and version number are defined in the vcpkg package manager.

[0059] In some embodiments, CMakeLists.txt is created in the root directory of the database program project to define how to build the program, such as what source code the program contains, which compilation options and linking options to use, and linking third-party library dependencies installed through vcpkg. Finally, the database executable file can be generated by running the CMake command.

[0060] In some embodiments, the specific process of generating an executable file of a database by running the CMake command can be: run CMake by specifying the CMake tool script path that comes with the vcpkg package manager; the CMake tool script automatically installs the dependent third-party library according to the vcpkg.json file in the current directory, and automatically sets the dependent third-party library path to the path that CMake can find; the CMake program uses the CMakeLists.txt in the current directory to build the database executable file.

[0061] Next comes the most critical part.

[0062] Usually, what C / C++ programmers learn is that the operation of C / C++ programs consists of the main program and some dependent libraries. The dependencies required for the program to run need to be pre-installed in the system. The developer's release program only includes the main program, and the program will use the dependencies installed by the system when it runs. For example, a program compiled with GCC 4.6 requires the GCC4.6C / C++ runtime library when it runs. This program may not be able to run directly on other target machines. This requires the installation of the GCC 4.6C / C++ runtime library on the target machine (similarly, the corresponding version libraries of other third-party libraries used when the program was compiled need to be installed).

[0063] In other words, C / C++ programmers usually think that C / C++ programs cannot run directly on other machines. However, Go programs can compile all source code (including third-party libraries) into an independent executable file during compilation. This file has no other dependencies, that is, it can be deployed with zero dependencies, which greatly improves deployment efficiency and reduces the operation and maintenance burden.

[0064] Although C / C++ does not compile all the codes together, we can still break the conventional thinking to achieve zero-dependency deployment and directly send the program package (note, it is no longer just the main program) to the user, who can run it directly.

[0065] The key to achieving zero-dependency deployment is:

[0066] Many developers know that the ldd command can check which libraries a program depends on. This embodiment can make innovative use of it: this embodiment does not use it for checking, but writes a shell script in which all third-party library dependencies of the program are recursively collected through the ldd command and the awk command, and all these dependencies and the ld interpreter program of the program are copied to the directory where the program file is located; then the copied ld interpreter is given executable permissions. Next, the ld interpreter path of the program is modified to the relative path of the ld interpreter in the directory where it is located through the patchelf file, and the rpath of the program is modified to the relative path of the directory where the program is located.

[0067] It should be noted that the embodiments of the present invention avoid the thinking inertia and thinking errors of many existing technologies. Although the tools used are existing tools, the scheme implemented is completely different from the existing methods of using these tools, and thus unexpected effects are achieved through the combination of these tools. For example:

[0068] 1. Usually, most programmers only use ldd to check which dependent libraries a program has, and never think of using it to assist in implementing a cross-platform deployment solution. However, the embodiment of the present invention uses ldd to assist in implementing a cross-platform deployment solution.

[0069] 2. Usually, most programmers do not know that executing programs under Linux requires an interpreter dynamic library, namely ELFinterpreter, and the dynamic library name is ld-linux.so, and they do not know that they can specify the path of the dynamic library used by the executable program.

[0070] 3. Usually, most programmers do not know that they can set the program's rpath to change the mechanism and location of the program's search for dependent libraries, and are not clear about the relationship and difference between the two.

[0071] 4. In addition, the conventional understanding of most programs is that C / C++ programs compiled under Linux cannot run across platforms. The embodiments of the present invention break this understanding.

[0072] Each of the above points may be known by some people, but it is necessary to clearly understand these technical points at the same time, not be bound by conventional cognition, dare to think about and solve problems, and be able to innovatively combine various knowledge and tools to achieve the goal, and then realize the cross-platform deployment solution as in the embodiment of the present invention. This has not appeared in the prior art.

[0073] Although ldd, awk and patchelf are existing tools, their functions are independent, and existing literature or technical solutions have never suggested using them together to solve the dynamic library optimization problem. The embodiment of the present invention realizes an efficient and automated processing flow through innovative tool combination and script design, which is a significant improvement over the existing technology.

[0074] Moreover, the specific process (such as ldd outputting dependency paths, awk parsing dependency paths, and the linkage processing with patchelf to modify the rpath path) reflects creative thinking rather than the intuitive choice of ordinary developers or engineers.

[0075] The embodiments of the present invention significantly reduce the time cost and error rate of manual operation, especially under complex or high-frequency requirements, and improve efficiency by several times. Through the solution of the embodiments of the present invention, cross-platform or dynamic library dependency path automatic adaptation can be achieved, filling the gap in flexibility of existing tools.

[0076] The embodiment of the present invention adheres to the core philosophy of Linux: "Each command focuses on a small task, and by cleverly combining multiple commands, an unimaginable effect can be achieved." This embodiment uses an innovative way of thinking to merge multiple programs to create an independent program that ultimately does not rely on system libraries. Through the above solution, a database program that can be deployed across platforms with zero dependencies can be built.

[0077] By preparing mainstream hardware machines such as x84, arm, mips, etc., and only needing to install a certain Linux operating system, you can use the above process to build a database program that can be deployed across platforms with zero dependencies, and it can run under both low-version and high-version operating systems.

[0078] In summary, the embodiment of the present invention provides a method for locally deploying a cross-platform graph database program. Through the innovative combination of vcpkg, CMake, ldd, patchelf and other technologies, developers can build a database program with zero dependency deployment; during the development process, developers do not need to manually install third-party dependency libraries, thereby reducing development costs and improving program building efficiency. More importantly, during the deployment process, you do not need to worry about the user's software environment, and you can deploy a distributed graph database program without installing dependency libraries in the user's local environment, so that the program can be compiled once and run in multiple places, greatly improving the work efficiency of database developers and implementers, and also improving the availability of user database services.

[0079] An embodiment of the present invention also provides a system for locally deploying a cross-platform graph database program, which applies the method for locally deploying a cross-platform graph database program as described above. The system includes a vcpkg creation module, a CMake creation module, an ldd command module, a path modification module, and a packaging and sending module, wherein: the vcpkg creation module is used to: deploy the vcpkg package manager, and create a vcpkg.json file in the directory where the program is located, and the vcpkg.json file includes the name and version number of the third-party library that the program depends on; the CMake creation module is used to: create CMakeLists.txt in the directory where the program is located, which is used to define how to build the program, and link it through vcpk g installed third-party libraries; generate the executable file of the database by running the CMake command; the ldd command module is used to: recursively collect all third-party libraries that the program depends on through the ldd command and the awk command, and copy all third-party libraries that the program depends on and the ld interpreter of the program to the directory where the program is located; the path modification module is used to: modify the ld interpreter path of the program to the relative path under the directory where the program is located through the patchelf file, and modify the rpath of the program to the relative path under the directory where the program is located; the packaging and sending module is used to: package the files in the directory where the program is located together and deliver them to the user, so that after the user deploys it, he can directly run the executable file to automatically install all third-party libraries that the program depends on. The specific functions of each module of the system have been explained in the corresponding method, so I will not repeat them here.

[0080] Embodiment 2:

[0081] Based on the method for locally deploying a cross-platform graph database program provided in the above-mentioned embodiment 1, embodiment 2 of the present invention provides a specific example for illustration.

[0082] Examples of the above scheme are as follows:

[0083] Third-party libraries are often used in program development. For example, a database program depends on third-party libraries such as libevent, grpc, protobuf, and upb. In order to compile the database program, you need to compile the third-party library files first. For the traditional way to compile dependent libraries, refer to Figure 3 As shown, first download the source code package from the library's official website to the local computer, then unzip the source code package to a local folder, and finally compile and install the library to the local library directory according to the tools and steps recommended in the compilation and installation document provided by the library. In the traditional development method, developers need to manually download a version of the source code package of these libraries from the Internet, and then manually compile each third-party library. The compilation method of each library may be different (some use CMake, some use automake, etc.), and usually multiple commands need to be specified to successfully compile, so the compilation process is very troublesome.

[0084] The method adopted in this embodiment is to write a vcpkg.json file according to the program's dependencies. The file is placed in the project root directory and the content is as follows:

[0085]

[0086]

[0087] In this file, "name" indicates the project name (depending on the project), and "version-string" defines the project version number. Note that this is not the version number of the dependency. In "dependencies", define the array of third-party libraries that the project depends on. Each array member represents a dependency, where "name" indicates the name of the dependent library, which is the name of the library in vcpkg, and "version" defines the version number of the dependent library.

[0088] When CMake is used to build the project later, vcpkg will be used to install dependencies according to vcpkg.json.

[0089] Note that this file defines the library name and version that the database program depends on, and also defines the baseline of vcpkg. This not only allows developers to know the dependent versions of the program more intuitively, but also avoids using the latest library when building the program due to vcpkg upgrading some dependent libraries, which may cause some unexpected behaviors (such as compilation failure, operation errors, etc.).

[0090] Then write CMakeLists.txt and store it in the project root directory. The core content is as follows:

[0091]

[0092]

[0093]

[0094] The purpose of this file is to find third-party library dependencies, add a list of source code files for building the database program, and then link the required third-party library dependencies. The cmake program can generate an executable file based on this file.

[0095] Then run the CMake command in the project root directory to build the database executable file:

[0096] cmake..-DCMAKE_TOOLCHAIN_FILE= / vcpkg / buildsystems / vcpkg.cmake

[0097] It runs CMake by specifying the path of the cmake tool script that comes with the vcpkg package manager. This script automatically installs dependencies according to the vcpkg.json file in the current directory (described above) and automatically sets the path of the dependencies to the path that CMake can find. Then the cmake program uses the CMakeLists.txt in the current directory to build the database executable file.

[0098] So far, we have completed the compilation process efficiently. The construction process of the entire program can be found in Figure 4 First, write vcpkg.json, in which you specify the name and version of the program's dependent library; then write CMakeLists.txt, which is used to define the project's source code list and library dependencies, as well as how to generate an executable program; then specify the vcpkg script as a parameter to run cmake, which automatically uses the vcpkg package manager to automatically download the source code of the dependent library from the Internet according to vcpkg.json and compile it; after running cmake, an executable file is generated.

[0099] Then, use the ldd, awk and other commands under Linux to recursively collect and copy the program's dependent libraries to the directory where the program is located. (Note: ldd is used to output which libraries the program depends on and the location of its dependent library files, and awk is a text processing program under Linux.)

[0100]

[0101]

[0102] At this point, the file list in the directory where the program is located is roughly as follows:

[0103] . / db_server

[0104] . / ld-interpreter.so

[0105] . / libevent.so

[0106] . / libupb.so

[0107] . / libprotobuf.so

[0108] . / libgrpc.so

[0109] Finally, the ld interpreter path and rpath of the program are modified through patchelf.

[0110] Usually, executable programs under Linux need to search for dependencies from the system directory. This is why it is conventionally believed that the user environment needs to have the dependency libraries required by the program, or the dependency libraries required by the separate program. Figure 5 As shown, under normal circumstances, the running program searches for dependent library files from the system library directory.

[0111] In order to avoid installing dependencies in the user environment (because manual installation may fail for some reasons), it is necessary to enable the program to search for dependencies from the directory where they are located (these dependency library files have been copied to the same directory as the program in the previous step).

[0112] . / patchelf --set-interpreter . / ld-interpreter.so "$1"

[0113] . / patchelf --set-rpath'$ORIGIN':'$ORIGIN' / . / "db_server" --force-rpath

[0114] This operation will make the program search for dependencies from the directory where its files are located when it runs. Figure 6 As shown, running the program searches for dependent library files in the directory where the program is located.

[0115] Finally, the files in the directory where the program is located are packaged and delivered to the user. After deployment, the db_server (executable file) can be run directly because its dependent library files are all in the directory where it is located, without the need for the user to manually install the dependencies. Figure 7As shown, the complete process of the above scheme includes: first write vcpkg.json, in which the name and version of the program dependency library are specified; then write CMakeLists.txt, which is used to define the source code list and library dependency of the project, and how to generate an executable program; then specify the vcpkg script as a parameter to run cmake, during which the vcpkg package manager is automatically used to automatically download the source code of the dependency library from the Internet according to vcpkg.json and compile it; after running cmake, an executable file is generated; then the library dependency file is copied to the directory where the program is located through the shell script; patchelf is used to modify the program file so that the library dependency file is found from the directory where the program is located; finally, the modified program and the library dependency files in its directory are packaged and delivered to the user.

[0116] So far, through the innovative combination of vcpkg, cmake, ldd, awk, xargs, patchelf and other commands, users can deploy database programs under any Linux operating system, which greatly improves the service quality; during the development process, it also reduces the burden of maintenance dependencies on developers.

[0117] Embodiment 3:

[0118] Based on the method for locally deploying a cross-platform graph database program provided in the above embodiment 1, the present invention also provides a device for locally deploying a cross-platform graph database program that can be used to implement the above method and system, such as Figure 8 , which is a schematic diagram of the device architecture of an embodiment of the present invention. The device for locally deploying a cross-platform graph database program in this embodiment includes one or more processors 21 and a memory 22. Figure 8 A processor 21 is taken as an example.

[0119] The processor 21 and the memory 22 may be connected via a bus or other means. Figure 8 The example of connecting through bus is taken in the following.

[0120] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as the method for locally deploying a cross-platform graph database program in Example 1. The processor 21 executes various functional applications and data processing of the device for locally deploying a cross-platform graph database program by running the non-volatile software programs, instructions and modules stored in the memory 22, that is, implements the method for locally deploying a cross-platform graph database program in Example 1.

[0121] The memory 22 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 22 may optionally include a memory remotely arranged relative to the processor 21, and these remote memories may be connected to the processor 21 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0122] The program instructions / modules are stored in the memory 22, and when executed by one or more processors 21, the method for locally deploying a cross-platform graph database program in the above-mentioned embodiment 1 is executed, for example, the above-described Figure 1 The steps shown.

[0123] The above-mentioned product can execute the method provided in the embodiment of the present application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of the present application.

[0124] It should be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0125] Through the description of the above implementation methods, ordinary technicians in this field can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, it can also be implemented by hardware. Ordinary technicians in this field can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0126] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them. Under the concept of the present invention, the technical features in the above embodiments or different embodiments may also be combined, the steps may be implemented in any order, and there are many other changes in different aspects of the present invention as described above, which are not provided in detail for the sake of simplicity. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for locally deploying a cross-platform graph database program, characterized in that: include: Deploy the vcpkg package manager and create a vcpkg.json file in the directory where the program is located. The vcpkg.json file includes the name and version number of the third-party library that the program depends on; Create CMakeLists.txt in the program directory to define how to build the program and link the third-party library installed by vcpkg; generate the executable file of the database by running the CMake command; Use the ldd command and awk command to recursively collect all third-party libraries that the program depends on, and copy all third-party libraries that the program depends on and the program's ld interpreter to the directory where the program is located; Through the patchelf file, modify the program's ld interpreter path to the relative path under the program's directory, and modify the program's rpath to the relative path under the program's directory; Package the files in the directory where the program is located and deliver them to the user. After deployment, the user can directly run the executable file to automatically install all third-party libraries that the program depends on.

2. The method for locally deploying a cross-platform graph database program according to claim 1, characterized in that: Deploying the vcpkg package manager specifically includes: Deploy the vcpkg package manager in the development CI environment of the database developer to configure the third-party libraries that the installer depends on according to the vcpkg.json file provided by the project.

3. The method for locally deploying a cross-platform graph database program according to claim 2, characterized in that: The names and version numbers of the third-party libraries that the program depends on are defined in the vcpkg package manager.

4. The method for locally deploying a cross-platform graph database program according to claim 1, characterized in that: The definition of how to construct a program specifically includes: defining the source code included in the program and the compile options and link options used.

5. The method for locally deploying a cross-platform graph database program according to claim 4, characterized in that: The executable file of the database generated by running the CMake command specifically includes: Run CMake by specifying the CMake tool script path that comes with the vcpkg package manager; The CMake tool script automatically installs the dependent third-party libraries according to the vcpkg.json file in the current directory, and automatically sets the dependent third-party library path to the path that CMake can find; The CMake program uses the CMakeLists.txt in the current directory to build the database executable file.

6. The method for locally deploying a cross-platform graph database program according to claim 1, characterized in that: The ldd command is used to output which third-party libraries the program depends on and the locations of the dependent third-party library files.

7. The method for locally deploying a cross-platform graph database program according to claim 1, characterized in that: After all third-party libraries that the program depends on and the ld interpreter of the program are copied to the directory where the program is located, the copied ld interpreter is given executable permission.

8. A device for locally deploying a cross-platform graph database program, characterized in that: The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the method for locally deploying a cross-platform graph database program as described in any one of claims 1-7.

9. A system for locally deploying a cross-platform graph database program, using the method for locally deploying a cross-platform graph database program as described in any one of claims 1 to 7, characterized in that: The system includes a vcpkg creation module, a CMake creation module, an ldd command module, a path modification module, and a packaging and sending module, wherein: The vcpkg creation module is used to: deploy the vcpkg package manager and create a vcpkg.json file in the directory where the program is located. The vcpkg.json file includes the name and version number of the third-party library that the program depends on; The CMake creation module is used to: create CMakeLists.txt in the directory where the program is located, which is used to define how to build the program and link the third-party library installed by vcpkg; generate an executable file of the database by running the CMake command; The ldd command module is used to: recursively collect all third-party libraries that the program depends on through the ldd command and the awk command, and copy all third-party libraries that the program depends on and the ld interpreter of the program to the directory where the program is located; The path modification module is used to: modify the ld interpreter path of the program to a relative path under the directory where the program is located, and modify the rpath of the program to a relative path under the directory where the program is located through the patchelf file; The packaging and sending module is used to package the files in the directory where the program is located and deliver them to the user, so that after the user deploys the program, he can directly run the executable file to automatically install all the third-party libraries that the program depends on.

10. A non-volatile computer storage medium, characterized in that: The computer storage medium stores computer executable instructions, which are executed by one or more processors to complete the method for locally deploying a cross-platform graph database program as described in any one of claims 1-7.

Images