Construction method and device of source code, storage medium and electronic equipment

Abstract

The present disclosure relates to a source code construction method and device, a storage medium and an electronic device, and relates to the technical field of computers. The method comprises: parsing a binary construction instruction, the binary construction instruction comprising a target project name, a target branch name and a Pod module name that needs to be binary; pulling the source code to be processed according to the target project name and the target branch name, and executing a Pod update instruction corresponding to the Pod module name that needs to be binary to obtain a Pod library that needs to be updated included in the Pod module name that needs to be binary; determining a binary construction program required for executing the binary construction instruction according to a device category of a terminal device; and based on the binary construction program and a preset compilation tool, performing a compilation construction of the source code to be processed corresponding to the Pod library that needs to be updated to obtain a construction product of the Pod library that needs to be updated. The method improves the project development efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method for constructing source code, an apparatus for constructing source code, a computer-readable storage medium, and an electronic device. Background Technology

[0002] In existing binary build methods for source code, the binary build process can be directed to the relevant project developers. However, since binary builds take a long time, this reduces the development efficiency of project developers.

[0003] It should be noted that the information in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this disclosure is to provide a method for constructing source code, a device for constructing source code, a computer-readable storage medium, and an electronic device, thereby overcoming, at least to some extent, the problem of low development efficiency caused by the limitations and defects of related technologies.

[0005] According to one aspect of this disclosure, a method for building source code is provided, configured on a Jenkins build machine, the method comprising: Receive binary build instructions sent by the terminal device and parse the binary build instructions, which include the target project name, the target branch name, and the name of the Pod module to be binary-coded. Pull the source code to be processed according to the target project name and target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryed to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryed. The binary build program required to execute the binary build instructions is determined based on the device category of the terminal device. Based on the binary build program and the preset compilation tools, the source code to be processed corresponding to the Pod library that needs to be updated is compiled and built to obtain the build product of the Pod library that needs to be updated.

[0006] According to one aspect of this disclosure, a source code building apparatus is provided, configured in a Jenkins packaging machine, the source code building apparatus comprising: The instruction parsing module is used to receive binary build instructions sent by the terminal device and parse the binary build instructions, which include the target project name, the target branch name, and the name of the Pod module to be binary-coded. The update instruction execution module is used to pull the source code to be processed according to the target project name and the target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryed, so as to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryed; A binary build program determination module is used to determine the binary build program required to execute the binary build instructions based on the device category of the terminal device; The compilation and build module is used to compile and build the source code corresponding to the Pod library to be updated based on the binary build program and the preset compilation tools, so as to obtain the build product of the Pod library to be updated.

[0007] According to one aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for constructing the source code as described in any of the preceding claims.

[0008] According to one aspect of this disclosure, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to execute the source code construction method described in any of the preceding embodiments via executing the executable instructions.

[0009] This disclosure provides a source code building method. On one hand, it receives and parses a binary build instruction sent by a terminal device. The binary build instruction includes the target project name, target branch name, and the name of the Pod module to be binary-coded. Then, it pulls the source code to be processed based on the target project name and target branch name, and executes the Pod update instruction corresponding to the Pod module name to be binary-coded, obtaining the Pod library to be updated included in the Pod module name. Next, it determines the binary build program required to execute the binary build instruction based on the device type of the terminal device. Finally, based on the binary build program and a preset compilation tool, it executes the compilation and building of the source code to be processed corresponding to the Pod library to be updated, obtaining the build product of the Pod library to be updated. Since the binary build of the source code is executed on the Jenkins packaging machine, project developers do not need to wait for the binary build, thus avoiding the problem of reduced development efficiency due to the long time required for binary build. On the other hand, since the binary build of the source code is performed by the Jenkins packaging machine using a unified compilation tool, it avoids compatibility issues caused by different versions of the compilation tools used.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0012] Figure 1 The diagram illustrates a specific implementation example of adding the CCVideoPlayerModule library to the binary.

[0013] Figure 2 The diagram illustrates a specific example of debinding the CCMetalKit library.

[0014] Figure 3 The diagram illustrates a specific example of adding the CCCrash library to a binary.

[0015] Figure 4The diagram illustrates a specific implementation example of debinding the CCCustomShare library.

[0016] Figure 5 A flowchart illustrating a method for constructing source code according to an exemplary embodiment of this disclosure is shown schematically.

[0017] Figure 6 A block diagram illustrating a source code building system according to an exemplary embodiment of the present disclosure is shown.

[0018] Figure 7 The diagram illustrates an example interface for manually performing a binary build on the ModuleBinSubmitter project page, according to an example embodiment of this disclosure.

[0019] Figure 8 The diagram illustrates an application scenario of remotely triggering a one-click Pod plugin according to an example embodiment of this disclosure.

[0020] Figure 9 The diagram illustrates a code example of a one-click Pod plugin remote triggering according to an exemplary embodiment of this disclosure.

[0021] Figure 10 A flowchart illustrating another method for constructing source code according to an example embodiment of this disclosure is shown schematically.

[0022] Figure 11 A block diagram schematically illustrates a source code construction apparatus according to an exemplary embodiment of the present disclosure.

[0023] Figure 12 An electronic device for implementing the above-described source code construction method is illustrated according to an example embodiment of the present disclosure. Detailed Implementation

[0024] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of these specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0025] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0026] To accelerate project compilation, some live streaming projects pre-compile the source code of infrequently modified Pod libraries into static libraries. During this binary compilation process, for these infrequently modified Pod libraries, the main project's build process directly relies on the pre-compile static libraries, rather than the source code within the Pod libraries themselves. Furthermore, in practical applications, the functionality of binary compiling Pod library source code into static libraries can be implemented using the `binary_install` and `module_install` modules within a custom third-party library management tool for the live streaming project (such as CocoaPods). The `binary_install` module can be used to binary compile all Pod libraries declared with the `Pod` keyword into static libraries and merge them into `PodsStaticLibrary.a`. Similarly, the `module_install` module can be used to binary compile all Pod libraries declared with the `cc_module_pod` keyword into static libraries.

[0027] In some solutions for converting Pod library source code into a static library, this can be achieved as follows: All developers involved in the aforementioned live streaming project can convert a specific Pod library in their project into a static library and commit it to the Git repository. The specific process for converting a Pod library into a static library involves modifying the binary conversion-related switch configuration in the Podfile or Podfile_CCModule file, and then executing `pod install` to trigger the build. The build process may include the following steps: First, developers modify the binary configuration of Pod libraries in the Podfile or Podfile_CCModule file. Specifically, for Pod libraries declared with the `Pod` keyword, adding them to `binary_install_excluded_targets` means they do not need to be binary-coded, and vice versa. For a concrete example, please refer to [link to example diagram]. Figure 1 as well as Figure 2 As shown; where, Figure 1 This is a concrete implementation example diagram of adding the CCVideoPlayerModule library to the binary. Figure 2 This is a concrete example diagram illustrating the implementation of disabling binary generation for the CCMetalKit library. Furthermore, for Pod libraries declared using the `cc_module_pod` keyword, adding `:module_bin => false` indicates that binary generation is not required, and adding `:module_bin => true` indicates that binary generation is required. For specific example diagrams, please refer to... Figure 3 as well as Figure 4 As shown; where, Figure 3 This is a concrete example diagram of adding the CCCrash library to binary format. Figure 4 This is a specific implementation example diagram of removing the binary version of the CCCustomShare library; Secondly, after the developers modify the above configuration, executing `pod install` or `pod update module_name` triggers the binary (or unbind) process for those Pod libraries whose configurations have changed; Finally, the developers submit the changes to the Podfile or Podfile_CCModule file, along with the build artifacts generated during the binary (or unbinding) process (static libraries, static library information, and changes to the project's linking configuration) to the Git repository for storage.

[0028] In other words, in practical applications, the local Pod library binary build scheme can be implemented as follows: First, developers manually modify the Podfile and Podfile_CCModule configuration files to indicate whether the Pod library needs to be binary-coded. Specifically, for Pod libraries declared with the `Pod` keyword, adding them to `binary_install_excluded_targets` means they do not need to be binary-coded, and vice versa. Similarly, for Pod libraries declared with the `cc_module_pod` keyword, adding `:module_bin→false` indicates they do not need to be binary-coded, and adding `:module_bin→true` indicates they need to be binary-coded. Second, execute `pod install` or `pod update module_name`, which triggers the binary build process in the custom CocoaPods plugin. This binary build process generates the following build artifacts: static library, static library information, and changes to project linking conditions. Finally, developers manually commit the changes to the Podfile and Podfile_CCModule configuration files, as well as all the aforementioned build artifacts, to Git.

[0029] However, in the aforementioned solutions, the process of building a Pod library into a static library and the Git commit of the build artifacts are both handled by the project developers. Therefore, the following problems exist in the implementation: First, there is a security risk of tampering with the static library: although the MD5 value of the newly built static library is recorded for verification after the Pod library is binary-coded, if the static library and the recorded MD5 value are tampered with together, the verification logic can be bypassed. Second, the binary-coding build process requires a long waiting time: developers need to wait for the build process to finish before they can commit the changes to the Podfile or Podfile_CCModule file and the build artifacts to the Git repository, wasting their time. Third, the Xcode version used for binary-coding is uncontrollable: the binary-coding process depends on the developer's local Xcode command-line tool, and different developers may use different Xcode versions. Static library artifacts built using certain Xcode versions may have system compatibility issues on some iOS systems, so it cannot be guaranteed that the static libraries tracked in the Git repository are built using a stable Xcode version.

[0030] Based on the problems described above, this exemplary embodiment first provides a method for building source code, which can run on a Jenkins packaging machine; of course, those skilled in the art can also run the method disclosed herein on other platforms as needed, and this exemplary embodiment does not impose any special limitations on this. Specifically, refer to... Figure 5 As shown, the method for constructing this source code may include the following steps: Step S510. Receive the binary build instruction sent by the terminal device and parse the binary build instruction, which includes the target project name, the target branch name, and the name of the Pod module to be binary-coded. Step S520. Pull the source code to be processed according to the target project name and target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryed to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryed; Step S530. Determine the binary build program required to execute the binary build instructions based on the device category of the terminal device; Step S540. Based on the binary build program and the preset compilation tools, execute the compilation and build of the source code to be processed corresponding to the Pod library that needs to be updated, and obtain the build product of the Pod library that needs to be updated.

[0031] In the aforementioned source code construction method, on the one hand, the binary build command sent by the terminal device is received and parsed. The binary build command includes the target project name, target branch name, and the name of the Pod module to be binary-coded. Then, the source code to be processed is pulled according to the target project name and target branch name, and the Pod update command corresponding to the Pod module name to be binary-coded is executed to obtain the Pod library to be updated included in the Pod module name to be binary-coded. Then, the binary build program required to execute the binary build command is determined according to the device type of the terminal device. Finally, based on the binary build program and the preset compilation tools, the compilation and construction of the source code to be processed corresponding to the Pod library to be updated is executed to obtain the build product of the Pod library to be updated. Since the binary build of the source code is executed on the Jenkins packaging machine, the project developers do not need to wait for the binary build of the source code, thus avoiding the problem of reduced development efficiency due to the long time required for binary build. On the other hand, since the binary build of the source code is compiled and built by the Jenkins packaging machine using a unified compilation tool, the compatibility problem caused by different versions of the compilation tools used can be avoided.

[0032] The following will provide a detailed explanation and description of the construction method of the historical source code of this disclosure, in conjunction with the accompanying drawings.

[0033] First, the inventive purpose of the exemplary embodiments of this disclosure will be explained and described. Specifically, the source code construction method described in the exemplary embodiments of this disclosure migrates the binary construction process of the Pod library from the local machine to a remote packaging machine, and changes the manual construction and submission of build artifacts to automatic service construction and submission of artifacts, thereby ensuring the reliability and standardization of the static library construction process. At the same time, after restricting the local binary construction of the Pod library by project developers, it also provides project developers with three ways to trigger the construction of the remote Pod library, fully supporting the remote Pod library binary construction scheme.

[0034] Secondly, the source code construction system involved in the exemplary embodiments of this disclosure will be explained and described. Specifically, refer to... Figure 6 As shown, the source code build system may include a terminal device 610, a Jenkins packager 620, and a Git repository 630. The terminal device can communicate with the Jenkins packager and the Git repository via a wired or wireless network; similarly, the Jenkins packager can also communicate with the Git repository via a wired or wireless network. In practical applications, the Jenkins packager can be used to implement the source code build method described in the example embodiments of this disclosure, the terminal device can be used to generate binary build instructions, and the Git repository can be used to store the source code and build artifacts. Furthermore, the terminal device described herein may include a first terminal device with a Jenkins packager client, a second terminal device containing the Git repository, and a third terminal device where developers reside. That is, in practical applications, a remote triggering module for binary builds can be set on the terminal device side; for example, a manual triggering module for the Jenkins packager can be set on the first terminal device side, a remote triggering module for GitLab continuous integration can be set on the second terminal device side, and a remote triggering module for one-click Pod plugins can be set on the third terminal device side.

[0035] Furthermore, in a source code construction method provided in the exemplary embodiments of this disclosure: In step S510, a binary build instruction sent by a terminal device is received and the binary build instruction is parsed. The binary build instruction includes the target project name, the target branch name, and the name of the Pod module to be binary-coded.

[0036] In this example embodiment, firstly, a binary build instruction sent by a terminal device is received. The specific process of receiving the binary build instruction can be implemented in the following ways: one is to receive a first binary build instruction generated and sent by a first terminal device when it detects a first screen input event acting on the binary build submitter; another is to receive a second binary build instruction triggered by the continuous integration script of the Git repository when a second terminal device receives additional information including the binary module name; yet another is to receive a third binary build instruction triggered by a third terminal device when it detects a second screen input event acting on a preset Pod plugin, selects the Pod module name to be binary-coded from the source files of a third-party library, and invokes the third binary build instruction based on the Pod module name to be binary-coded.

[0037] In one example embodiment, the first binary build instruction described above is generated as follows: First, in response to a first screen input event acting on the binary build submitter, a list of project names to be binary-built is displayed on the display interface of the first terminal device; second, in response to a selection operation acting on the current project name in the project name list, a target project name is determined, and a list of current branches corresponding to the target project name is displayed on the display interface of the first terminal device; then, in response to a selection operation acting on the current branch list, a target branch name is determined, and a list of Pod module names corresponding to the target branch name is displayed on the display interface of the first terminal device; finally, in response to a selection operation acting on the current Pod module name in the Pod module name list, a Pod module name to be binary-coded is determined, and the first binary build instruction is generated based on the target project name, the target branch name, and the Pod module name to be binary-coded.

[0038] In one example embodiment, the second binary build instruction described above is generated by the second terminal device in the following manner: First, when it is detected that there is a need to push Git commit information to a remote repository, a GitLab continuous integration script is executed, and it is determined based on the GitLab continuous integration script whether the Git commit information includes additional information of the binary module name; second, if the Git commit information includes additional information of the binary module name, the second binary build instruction is generated based on the target project name, target branch name, and Pod module name to be binary-ified included in the additional information of the binary module name.

[0039] In one example embodiment, the third binary build instruction described above is generated by a third terminal device in the following manner: First, in response to a second screen input event acting on a preset Pod plugin, a list of source files of a third-party library to be binary-built is displayed on the display interface of the third terminal device; second, in response to a selection operation acting on the source file list of the third-party library, a target source file of the third-party library is selected from the source file list of the third-party library, and a list of module names corresponding to the target source file of the third-party library is displayed on the display interface of the third terminal device; then, in response to a selection operation acting on the list of module names, the Pod module name to be binary-built is determined from the current module name in the list of module names; finally, a third binary build instruction is generated based on the Pod module name to be binary-built, and the target project name and target branch name corresponding to the Pod module name to be binary-built.

[0040] The following will explain and illustrate the specific build process of binary build commands. Specifically, developers of relevant projects can trigger remote binary builds in the following ways, i.e., generate binary build commands in the following ways: One implementation is to log in to the Jenkins packager CCModuleBinSubmitter project and build directly (CC here can refer to the target project name); that is, relevant project developers can log in to the client set on the first terminal device and then manually perform a binary build on the ModuleBinSubmitter (binary build submitter) project page; For specific interface display screenshots, please refer to... Figure 7Another implementation is to use the Git commit message with the `#bin` (binary) module name to trigger a GitLab continuous integration script to initiate a remote build. That is, project developers can include the `#bin` module name in their Git commit messages to trigger GitLab CI to execute a remote binary build script. Specifically, when GitLab detects a Git commit being pushed to a remote repository, it executes a GitLab CI script, which can then determine whether the Git commit message contains `#bin`. If XXX is included, the Jenkins build API (first application interface) is invoked. This first application interface can be in a format similar to: "http: / / {}:{}@jenkins.cc-ios.com / me / my-views / view / all / job / CCModuleBinSubmitter / buildWithParameters".format(USER_NAME, API_TOEKN), passing fields such as PROJECT_NAME (target project name), BRANCH (target branch name), POD_NAME (pod module name to be binary-coded), TRIGGER_USER (triggering user information), and OTHER_MESSAGE to the build engine. Alternatively, the one-click Pod plugin can select a module name from the Podfile or Podfile_CCModule and trigger a script to initiate a remote build. That is, the one-click Pod plugin options can be expanded to support placing the cursor in the Podfile or Podfile_CCModule in Xcode. The file declares a Pod library using the `pod` keyword or the `cc_module_pod` keyword. Then, clicking Xcode menu → Editor → OneKeyPodExtension → Remote Pod Library Binary will launch a terminal and execute the shell script `trigger_module_bin.sh`, thus triggering the remote binary build of the corresponding Pod library. For specific application scenario diagrams, please refer to... Figure 8 As shown, the specific execution process diagram can be found in the image. Figure 9As shown; further, after confirmation, it essentially involves calling the Jenkins build API (second application interface) and passing fields such as ROJECT_NAME, BRANCH, POD_NAME, TRIGGER_USER, and OTHER_MESSAGE to the Jenkins build machine; the second application interface described here can be generated in a manner similar to the following: "http: / / {}:{}@jenkins.cc-ios.com / me / my-views / view / all / job / CCModuleBinSubmitter / buildWithParameters".format(USER_NAME, API_TOEKN)).

[0041] It should be noted that the Jenkins builder CCModuleBinSubmitter (binary build committer) described in this example embodiment may have the following functions, including but not limited to: ① Support for selecting the project name PROJECT_NAME, which may include projects such as CC Live and CC Voice, or other project names; this example does not impose any special restrictions on this. ② Support for selecting the branch name BRANCH of the project repository; specifically, in actual application, selecting PROJECT_NAME will switch the display of the corresponding project repository's branch list. ③ Support for notifying the builder to pull the latest branch list via GitLab Webhook. ④ Support for selecting the Pod module name POD_NAME to be binary-coded; specifically, in actual application, selecting PROJECT_NAME will switch the display of the corresponding project's Pod module name list. ⑤ Support for retrieving data from Podfile and Podfile_CCModule. The regular expression matches all module names and sorts them alphabetically; ⑥ It supports adding extra information (such as #order number) OTHER_MESSAGE to the Git commit message; ⑦ It supports adding the remote trigger user TRIGGER_USER to the Git commit message.

[0042] It's worth noting that in practical applications, project developers can manually modify (or have the packaging service automatically modify) the Podfile and Podfile_CCModule configuration files locally to determine whether Pod libraries need to be binary-coded. Additionally, for Pod libraries declared with the `pod` keyword, adding them to `binary_install_excluded_targets` indicates they don't need binary-coding, and vice versa. Furthermore, for Pod libraries declared with the `cc_module_pod` keyword, adding `:module_bin=> false` indicates they don't need binary-coding, and adding `:module_bin => true` indicates they need binary-coding.

[0043] In step S520, the source code to be processed is pulled according to the target project name and the target branch name, and the Pod update instruction corresponding to the Pod module name that needs to be binary is executed to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binary.

[0044] In this example embodiment, firstly, the source code to be processed is pulled according to the target project name and the target branch name. Specifically, this can be achieved as follows: The target branch name corresponding to the target project name is switched using a Git branch checking tool, and the source code to be processed corresponding to the target branch name is pulled from the Git repository using a Git working directory reset tool and a Git pull tool. That is, in practical applications, `git checkout {branch}` (a Git branch checking tool) can be used to switch branches or check out branches; then, `git reset --hard` (a Git working directory reset tool) and `git pull` (a Git pull tool) are used to reset the working directory and pull the latest code from the remote repository, i.e., the source code to be processed corresponding to the target branch name is pulled from the Git repository.

[0045] Secondly, after retrieving the source code to be processed, the Pod update instruction corresponding to the Pod module name that needs to be binary-coded can be executed to obtain the Pod libraries that need to be updated included in the Pod module name that needs to be binary-coded. Specifically, this can be achieved as follows: First, find the original Pod library corresponding to the extension file of the third-party library corresponding to the target branch name, and find the source file of the third-party library corresponding to the target branch name; second, update the current binary-coded list in the original Pod library according to the Pod module names that need to be binary-coded, and update the Pod module names that do not need to be binary-coded in the current binary-coded list according to the source files to obtain the target name list; then, execute the Pod update instruction corresponding to the target name list to obtain the Pod libraries that need to be updated included in the Pod module names that need to be binary-coded. In other words, first, it needs to search for the corresponding Pod library information in Podfile_CCModule (an extension file of the Podfile used to declare modules) and update it: module_bin (binary options) → Options. Then, it searches for the Podfile (the file in CocoaPods that declares third-party libraries) and updates the binary_install_excluded_targets (a collection of component library names that do not need to be binary-coded) list. Finally, it executes pod update (a command provided by CocoaPods to update third-party libraries, which can specify to update a specific library) module_name --repo-update, which will give you the Pod libraries that need to be updated included in the Pod module name that needs to be binary-coded.

[0046] In step S530, the binary build program required to execute the binary build instructions is determined according to the device category of the terminal device.

[0047] Specifically, the device category of the terminal device described herein may include a first device category and a second device category; wherein, when the terminal device is a first terminal device, it is determined that the terminal device has a first device category; the first device category is a Jenkins packaging machine device; simultaneously, when the terminal device is a second terminal device and / or a third device, it is determined that the terminal device has a second device category; the second device category is a device corresponding to the project developer; further, determining the binary build program required to execute the binary build instruction based on the device category of the terminal device can be achieved in the following way: first, trigger a third-party library management tool, and determine the device category of the terminal device based on the device identifier included in the binary build instruction; second, when the device category of the terminal device is the first device category, determine the binary build program required to execute the binary build instruction as the first build program; further, when the device category of the terminal device is the second device category, determine the binary build program required to execute the binary build instruction as the second build program. In other words, in practical applications, firstly, the third-party library management tool CocoaPods is triggered. Then, based on the device identifier included in the binary build instructions, it is determined whether the terminal device belongs to the development team member or the packaging machine. If it is the packaging machine, the first build process is executed; if it belongs to the developer's terminal device, the second build process is executed. The first build process directly executes the corresponding compilation and build, while the second build process executes the corresponding process based on the category of the keywords declared in the Pod library. The specific execution process will be explained in detail later and will not be elaborated further here.

[0048] In step S540, based on the binary build program and the preset compilation tools, the source code to be processed corresponding to the Pod library to be updated is compiled and built to obtain the build product of the Pod library to be updated.

[0049] In this example embodiment, based on the binary build program and the preset compilation tools, the source code to be processed corresponding to the Pod library that needs to be updated is compiled and built to obtain the build artifact of the Pod library that needs to be updated. This can be achieved in the following two ways: The first implementation involves using a first build program and a pre-defined compilation tool to compile and build the source code corresponding to the Pod library to be updated, resulting in the build artifacts of the Pod library to be updated. Specifically, this can be achieved as follows: using the pre-defined compilation tool, compile and build the source code corresponding to the Pod library to be updated, resulting in the build artifacts of the Pod library to be updated; wherein, the build artifacts include static libraries, static library information, and changes to project linking conditions, etc.; furthermore, after obtaining the build artifacts, the packaging machine automatically commits the changes to the Podfile and Podfile_CCModule configuration files, as well as all the aforementioned build artifacts, to the Git repository; that is, after the compilation and build are completed, the packaging machine automatically commits the build artifacts, Podfile, and Podfile_CCModule configuration file changes to the Git repository.

[0050] It's worth noting that to avoid conflicts, you can pull the repository again before committing to Git. That is, if content updates occur during the process of pulling the latest code from the remote Git repository and executing the update command, repeat the above steps after pulling. To determine if content updates have occurred, you can use `git log --left-right --oneline origin / development... development` to check if the remote Git repository has content to pull. If the remote Git repository has no updates, append the task number (#task number), the binary Pod library name, and the triggering user's username (or email address) to the commit message before committing. Additionally, when an execution exception occurs at the start of the build, the end of the build, or at any step of the above process, corresponding notification messages will be sent to the user, such as email notifications.

[0051] The second implementation method is as follows: Based on the second build program and the preset compilation tools, the compilation and construction of the source code corresponding to the Pod library to be updated is executed to obtain the build product of the Pod library to be updated. Specifically, this can be achieved as follows: First, obtain the keyword that declares the Pod library to be updated; second, if the keyword of the Pod library to be updated is a first keyword category, then parse the binaryization option of the Pod library to be updated; then, if the Pod library to be updated does not have a binaryization option, then import the Pod library to be updated in source code form; if the Pod library to be updated has a binaryization option, then import the Pod library to be updated in binary form; finally, based on the preset compilation tools, the compilation and construction of the source code corresponding to the imported Pod library to be updated is executed to obtain the build product of the Pod library to be updated.

[0052] In one example embodiment, the above-described method for constructing source code further includes: if the keyword of the Pod library to be updated is a second keyword category, then analyzing the changes between the current attribute file and the historical attribute file of the Pod library to be updated; if changes exist, then stopping the execution of the binary conversion instruction; if no changes exist, then determining whether the Pod library to be updated needs to be rebuilt using binary conversion; if it needs to be rebuilt using binary conversion, then stopping the execution of the binary conversion instruction; if not, then executing the Pod update instruction corresponding to the name of the Pod module to be binary converted, obtaining the Pod library to be updated included in the name of the Pod module to be binary converted, and based on a preset compilation tool, executing the compilation and construction of the source code to be processed corresponding to the Pod library to be updated, to obtain the build product of the Pod library to be updated.

[0053] The following section will explain and illustrate the specific implementation process of compiling and building using the second method. Specifically, in practical applications, compared to the original local Pod library binary conversion process, for scenarios where team members perform binary builds locally, the following local binary build restrictions are imposed on Pod libraries declared with the `cc_module_pod` keyword (first category keyword) and the `pod` keyword (second category keyword); This restriction logic is placed in the project's custom CocoaPods plugin; furthermore, for Pod libraries declared with the `cc_module_pod` keyword that need updating, it can be implemented as follows: First, parse the `module_bin` option (binary option) of the Pod library declared with the `cc_module_pod` keyword. If the `module_bin` option is false (i.e., no binary option exists), the project will import the Pod library that needs updating in source code form; if the `module_bin` option is true (i.e., a binary option exists), there are two cases; where `module_bin` is true, it means the Pod library that needs updating should be imported in binary form. In specific applications, the first case is that previously it was imported in source code form, now it is imported in binary form. This case will interrupt `pod install` (or `pod install`). The second scenario is that if the Pod library was already introduced in binary form, then the subsequent processes of `pod install` (or `pod update`) will only be interrupted to restrict binary builds when the Pod library is updated. Of course, if the Pod library content remains unchanged, the subsequent processes of `pod install` (or `pod update`) will not be interrupted. Whether an update has been committed can be determined as follows: compare the Git commit SHA value in the static library information with the latest Git commit SHA value of the corresponding Pod library; if they match, no update has been made; if they do not match, an update has occurred.

[0054] Furthermore, for Pod libraries that require binary generation and are declared using the `pod` keyword, they will ultimately be merged into a single static library, `PodsStaticLibrary.a`. This is slightly more complicated. Specifically, it can be implemented as follows: First, analyze the changes in the `Podfile.lock` file compared to the `PodsBin.lock` file. The `Podfile.lock` file is generated by CocoaPods after parsing the `Podfile` and `Podfile_CCModule` files, containing information about each Pod library version, dependencies, paths, and other custom information. The `PodsBin.lock` file is the file created when the corresponding `Podfile.lock` file content was copied to the `PodsBin.lock` file during the last successful `pod install` or `pod update module name`. Second, iterate through and compare the list items in the `Podfile.lock` and `PodsBin.lock` files. If any additions or changes occur to the information of the Pod libraries requiring binary generation, then interrupt `pod install` (or `pod update module name`). The subsequent `pod install` (or `pod update`) process restricts binary builds. The `Podfile.lock` file records information about all Pod libraries declared using the `pod` and `cc_module_pod` keywords, regardless of whether a Pod library needs to be binary-coded. Therefore, Pod libraries declared using the `cc_module_pod` keyword and those defined in `binary_install_excluded_targets` that don't need binary-coding are filtered out. Furthermore, when the subsequent `pod install` (or `pod update`) process needs to be interrupted to restrict binary builds, the project developers are prompted: "Disable local binary-coding; please submit the XX library as source code," and the process ends. If neither of these conditions is met, the subsequent `pod install` or `pod update module_name` process continues. Finally, the project developers manually commit changes to the `Podfile`, `Podfile_CCModule` configuration files, and build artifacts (build artifacts related to Pod library source code dependencies, `PodsStaticLibrary.a` which removed the binary-coded Pod library, and changes to the project's linking configuration).

[0055] At this point, the method for constructing the source code described in the exemplary embodiments of this disclosure has been completed. The following will be combined with... Figure 10The method for constructing the source code described in the exemplary embodiments of this disclosure will be further explained and illustrated. Specifically, refer to... Figure 10 As shown, the method for constructing this source code may include the following steps: Step S1001: The terminal device generates binary build instructions and sends the binary build instructions to the Jenkins packaging machine; In step S1002, the Jenkins builder receives the binary build command and executes the Pod install or podupdate command to obtain the Pod library that needs to be updated. Step S1003: Call the post install hook in the CocoaPods plugin to determine the device category based on the device identifier; Step S1004: Determine whether the terminal device is a packaging machine based on the device category; if yes, proceed to step S1005; if no, proceed to step S1006. Step S1005: Based on the preset compilation tools, the compilation and building of the source code to be processed corresponding to the Pod library that needs to be updated is executed to obtain the build artifacts of the Pod library that needs to be updated, and the changes to the Podfile, Podfile_CCModule configuration files and the build artifacts are automatically committed to Git. Step S1006: Analyze the changes in the Podfile.lock file compared to the PodsBin.lock file; Step S1007: Determine whether the information of the pod library that needs to be binary declared by the pod keyword has been added or updated based on the change item; if yes, proceed to step S1008; if no, proceed to step S1009. Step S1008, generate error message: Local binary conversion function is disabled. Please submit the XX library as source code. Step S1009: Analyze whether the Pod library declared by the cc_module_pod keyword that needs to be binary-coded needs to be rebuilt into a binary; if yes, proceed to step S1008; if no, proceed to step S1010. In step S1010, continue the Pod install or pod update process and manually commit the changes to the Podfile, Podfile_CCModule configuration files, and build artifacts using Git.

[0056] Thus, the source code construction method described in the exemplary embodiments of this disclosure has been fully implemented. Based on the foregoing description, it can be seen that the source code construction method described in the exemplary embodiments of this disclosure has at least the following advantages: Firstly, it can ensure the security of the static library binary conversion process: it can ensure that the binary static library corresponds one-to-one with the Pod library source code, ensuring that the static library will not be maliciously tampered with; secondly, it can save the time of synchronously waiting for the generation of binary build artifacts: that is, the binary conversion construction process, which requires a long waiting time, can be executed asynchronously on the packaging machine, avoiding the time that team members need to synchronously wait for the generation of build artifacts, which improves the development efficiency of team members to a certain extent; thirdly, it can ensure that the Xcode version used for binary conversion is a stable and controllable version: that is, as long as a stable version of the Xcode command-line tool is deployed and installed on the packaging machine, it can be ensured that the binary static libraries are all built from this stable version of Xcode, reducing some uncontrollable iOS system compatibility issues.

[0057] This disclosure also provides an example embodiment of a source code build apparatus that can be configured on a Jenkins packaging machine. Specifically, see [link to documentation]. Figure 11 As shown, the source code building apparatus may include an instruction parsing module 1110, an update instruction execution module 1120, a binary builder determination module 1130, and a compilation and building module 1140. Wherein: The instruction parsing module 1110 can be used to receive binary build instructions sent by the terminal device and parse the binary build instructions, wherein the binary build instructions include the target project name, the target branch name, and the name of the Pod module to be binary-coded. The update instruction execution module 1120 can be used to pull the source code to be processed according to the target project name and the target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryized, so as to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryized; The binary build program determination module 1130 can be used to determine the binary build program required to execute the binary build instructions based on the device category of the terminal device; The compilation and build module 1140 can be used to compile and build the source code to be processed corresponding to the Pod library that needs to be updated, based on the binary build program and the preset compilation tools, so as to obtain the build product of the Pod library that needs to be updated.

[0058] In one exemplary embodiment of this disclosure, the terminal device includes one or more of the following: a first terminal device equipped with a Jenkins packaging machine client, a second terminal device containing a Git repository, and a third terminal device containing developers. The receiving of binary build instructions from terminal devices includes: receiving a first binary build instruction generated and sent by a first terminal device when it detects a first screen input event acting on the binary build submitter; or receiving a second binary build instruction triggered by the continuous integration script of the Git repository when a second terminal device receives additional information including the binary module name; or receiving a third binary build instruction triggered by a third terminal device when it detects a second screen input event acting on a preset Pod plugin, selecting the Pod module name to be binary-coded from the source files of a third-party library, and invoking the Pod module name to be binary-coded.

[0059] In one exemplary embodiment of this disclosure, the first binary build instruction is generated as follows: in response to a first screen input event acting on the binary build submitter, a list of project names to be binary-built is displayed on the display interface of the first terminal device; in response to a selection operation acting on the current project name in the project name list, a target project name is determined, and a list of current branches corresponding to the target project name is displayed on the display interface of the first terminal device; in response to a selection operation acting on the current branch list, a target branch name is determined, and a list of Pod module names corresponding to the target branch name is displayed on the display interface of the first terminal device; in response to a selection operation acting on the current Pod module name in the Pod module name list, a Pod module name to be binary-coded is determined, and the first binary build instruction is generated based on the target project name, the target branch name, and the Pod module name to be binary-coded.

[0060] In one exemplary embodiment of this disclosure, the second binary build instruction is generated by the second terminal device in the following manner: when it is detected that there is a need to push Git commit information to a remote repository, a GitLab continuous integration script is executed, and it is determined based on the GitLab continuous integration script whether the Git commit information includes additional information of the binary module name; if the Git commit information includes additional information of the binary module name, the second binary build instruction is generated according to the target project name, target branch name and Pod module name to be binary included in the additional information of the binary module name.

[0061] In one exemplary embodiment of this disclosure, the third binary build instruction is generated by a third terminal device in the following manner: in response to a second screen input event acting on a preset Pod plugin, a list of source files of a third-party library to be binary-built is displayed on the display interface of the third terminal device; in response to a selection operation acting on the source file list of the third-party library, a target source file of the third-party library is selected from the source file list of the third-party library, and a list of module names corresponding to the target source file of the third-party library is displayed on the display interface of the third terminal device; in response to a selection operation acting on the list of module names, the name of the Pod module to be binary-built is determined from the current module name in the list of module names; and a third binary build instruction is generated based on the name of the Pod module to be binary-built, the target project name, and the target branch name corresponding to the name of the Pod module to be binary-built.

[0062] In one exemplary embodiment of this disclosure, pulling the source code to be processed according to the target project name and the target branch name includes: switching the target branch name corresponding to the target project name based on the Git branch checking tool, and pulling the source code to be processed corresponding to the target branch name from the Git repository according to the Git workspace reset tool and the Git pull tool.

[0063] In one exemplary embodiment of this disclosure, executing a Pod update instruction corresponding to the Pod module name that needs to be binaryized to obtain the Pod libraries that need to be updated included in the Pod module name that needs to be binaryized includes: finding the original Pod library corresponding to the extension file of the third-party library corresponding to the target branch name, and finding the source file of the third-party library corresponding to the target branch name; updating the current binaryization list in the original Pod library according to the Pod module names that need to be binaryized, and updating the Pod module names that do not need to be binaryized in the current binaryization list according to the source file to obtain a target name list; executing a Pod update instruction corresponding to the target name list to obtain the Pod libraries that need to be updated included in the Pod module names that need to be binaryized.

[0064] In one exemplary embodiment of this disclosure, the device category includes a first device category and a second device category; when the terminal device is a first terminal device, it is determined that the terminal device has a first device category; the first device category is a Jenkins packaging machine device; when the terminal device is a second terminal device and / or a third device, it is determined that the terminal device has a second device category; the second device category is a device corresponding to a project developer. The process of determining the binary build program required to execute the binary build instruction based on the device category of the terminal device includes: triggering a third-party library management tool, and using the third-party library management tool to determine the device category of the terminal device based on the device identifier included in the binary build instruction; when the device category of the terminal device is a first device category, determining the binary build program required to execute the binary build instruction as a first build program; and when the device category of the terminal device is a second device category, determining the binary build program required to execute the binary build instruction as a second build program.

[0065] In one exemplary embodiment of this disclosure, based on a first build program and a preset compilation tool, the compilation and construction of the source code to be processed corresponding to the Pod library to be updated is performed to obtain the build product of the Pod library to be updated, including: based on the preset compilation tool, the compilation and construction of the source code to be processed corresponding to the Pod library to be updated is performed to obtain the build product of the Pod library to be updated; wherein, the build product includes one or more of the following: static library, static library information, and changes in project linking conditions.

[0066] In one exemplary embodiment of this disclosure, based on a second build program and a preset compilation tool, the compilation and construction of the source code to be processed corresponding to the Pod library to be updated is performed to obtain the build product of the Pod library to be updated, including: obtaining the keyword declaring the Pod library to be updated; if the keyword of the Pod library to be updated is a first keyword category, then parsing the binaryization option of the Pod library to be updated; if the Pod library to be updated does not have a binaryization option, then the Pod library to be updated is imported in source code form; if the Pod library to be updated has a binaryization option, then the Pod library to be updated is imported in binary form; based on the preset compilation tool, the compilation and construction of the source code to be processed corresponding to the imported Pod library to be updated is performed to obtain the build product of the Pod library to be updated.

[0067] In one exemplary embodiment of this disclosure, the source code construction apparatus further includes: The change item analysis module can be used to analyze the change items between the current attribute file and the historical attribute file of the Pod library that needs to be updated if the keyword of the Pod library that needs to be updated is the second keyword category. The binary build judgment module can be used to stop the execution of binary build instructions if there are changes; if there are no changes, it can determine whether the Pod library to be updated needs to be rebuilt using binary build. The update instruction execution submodule can be used to stop the execution of binary instructions if a re-binding is required; otherwise, it executes the Pod update instruction corresponding to the name of the Pod module that needs to be binary-coded.

[0068] The specific details of each module in the above source code construction device have been described in detail in the corresponding source code construction method, so they will not be repeated here.

[0069] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0070] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0071] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0072] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0073] The following reference Figure 12 To describe an electronic device 1200 according to such an embodiment of the present disclosure. Figure 12 The electronic device 1200 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0074] like Figure 12 As shown, the electronic device 1200 is manifested in the form of a general-purpose computing device. The components of the electronic device 1200 may include, but are not limited to: at least one processing unit 1210, at least one storage unit 1220, a bus 1230 connecting different system components (including storage unit 1220 and processing unit 1210), and a display unit 1240.

[0075] The storage unit stores program code that can be executed by the processing unit 1210, causing the processing unit 1210 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 1210 can perform actions such as... Figure 5 Step S510: Receive the binary build instruction sent by the terminal device and parse the binary build instruction, which includes the target project name, target branch name, and the name of the Pod module to be binary-coded; Step S520: Pull the source code to be processed according to the target project name and target branch name, and execute the Pod update instruction corresponding to the Pod module name to be binary-coded to obtain the Pod library to be updated included in the Pod module name to be binary-coded; Step S530: Determine the binary build program required to execute the binary build instruction according to the device category of the terminal device; Step S540: Based on the binary build program and the preset compilation tools, execute the compilation and build of the source code to be processed corresponding to the Pod library to be updated to obtain the build product of the Pod library to be updated.

[0076] Storage unit 1220 may include readable media in the form of volatile storage units, such as random access memory (RAM) 12201 and / or cache memory 12202, and may further include read-only memory (ROM) 12203.

[0077] Storage unit 1220 may also include a program / utility 12204 having a set (at least one) of program modules 12205, such program modules 12205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0078] Bus 1230 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0079] Electronic device 1200 can also communicate with one or more external devices 1300 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1200, and / or any device that enables electronic device 1200 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1250. Furthermore, electronic device 1200 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1260. As shown, network adapter 1260 communicates with other modules of electronic device 1200 via bus 1230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0080] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0081] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible implementations, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of this disclosure described in the "Exemplary Methods" section above.

[0082] The program product for implementing the above-described method according to embodiments of the present disclosure may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0083] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0084] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0085] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0086] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0087] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0088] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention described herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not invented by this disclosure. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

Claims

1. A method for constructing source code, characterized in that, Configured on the Jenkins build machine, the source code build method includes: Receive binary build instructions sent by the terminal device and parse the binary build instructions, which include the target project name, the target branch name, and the name of the Pod module to be binary-coded. Pull the source code to be processed according to the target project name and target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryized to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryized; The binary build program required to execute the binary build instructions is determined based on the device category of the terminal device. Based on the binary build program and the preset compilation tools, the source code to be processed corresponding to the Pod library that needs to be updated is compiled and built to obtain the build product of the Pod library that needs to be updated.

2. The method for constructing source code according to claim 1, characterized in that, The terminal devices include one or more of the following: a first terminal device with a client configured with a Jenkins packaging machine, a second terminal device containing a Git repository, and a third terminal device containing developers. The binary build instructions sent by the receiving terminal device include: Receive a first binary build instruction generated and sent by the first terminal device when it detects a first screen input event acting on the binary build submitter; or When the second terminal device receives additional information including the binary module name, it triggers a second binary build instruction invoked by the continuous integration script of the Git repository; or When a third terminal device detects a second screen input event acting on a preset Pod plugin, it selects the name of the Pod module to be binary from the source file of the third-party library and invokes a third binary build instruction based on the name of the Pod module to be binary.

3. The method for constructing source code according to claim 2, characterized in that, The first binary build instruction is generated in the following way: In response to a first screen input event acting on the binary build submitter, a list of project names to be executed for binary build is displayed on the display interface of the first terminal device; In response to a selection operation on the current project name in the project name list, a target project name is determined, and a current branch list corresponding to the target project name is displayed on the display interface of the first terminal device. In response to a selection operation applied to the current branch list, the target branch name is determined, and a list of Pod module names corresponding to the target branch name is displayed on the display interface of the first terminal device. In response to a selection operation on the current Pod module name in the list of Pod module names, the Pod module name that needs to be binary-coded is determined, and the first binary-coding instruction is generated based on the target project name, the target branch name, and the Pod module name that needs to be binary-coded.

4. The method for constructing source code according to claim 2, characterized in that, The second binary build instruction is generated by the second terminal device in the following manner: When it is detected that there is a need to push Git commit information to the remote repository, the GitLab continuous integration script is executed, and the GitLab continuous integration script is used to determine whether the Git commit information includes additional information such as the binary module name. If the Git commit message includes additional information about the binary module name, then a second binary build instruction is generated based on the target project name, target branch name, and the Pod module name to be binary-ified included in the additional information about the binary module name.

5. The method for constructing source code according to claim 2, characterized in that, The third binary construction instruction is generated by the third terminal device in the following manner: In response to a second screen input event acting on a preset Pod plugin, a list of source files for a third-party library to be binary-built is displayed on the display interface of the third terminal device; In response to a selection operation on the source file list of the third-party library, a target source file of the third-party library is selected from the source file list of the third-party library, and a list of module names corresponding to the target source file of the third-party library is displayed on the display interface of the third terminal device. In response to a selection operation performed on the list of module names, determine the Pod module name that needs to be binary-coded from the current module names in the list of module names; Generate a third binary build instruction based on the required binary Pod module name, as well as the target project name and target branch name corresponding to the required binary Pod module name.

6. The method for constructing source code according to claim 1, characterized in that, Retrieve the source code to be processed based on the target project name and target branch name, including: The Git branch inspection tool switches the target branch name to the target project name, and the Git workspace reset tool and Git pull tool pull the source code to be processed corresponding to the target branch name from the Git repository.

7. The method for constructing source code according to claim 1, characterized in that, Execute the Pod update instruction corresponding to the Pod module name that needs to be binary-coded, and obtain the Pod libraries that need to be updated included in the Pod module name that needs to be binary-coded, including: Locate the original Pod library corresponding to the extended file of the third-party library corresponding to the target branch name, and locate the source file of the third-party library corresponding to the target branch name; The current binary list in the original Pod library is updated according to the Pod module names that need to be binaryized, and the Pod module names that do not need to be binaryized in the current binary list are updated according to the source file to obtain the target name list; Execute the Pod update instruction corresponding to the target name list to obtain the Pod libraries that need to be updated, which are included in the Pod module names that need to be binary-ified.

8. The method for constructing source code according to claim 1, characterized in that, The equipment categories include a first equipment category and a second equipment category; When the terminal device is a first terminal device, it is determined that the terminal device has a first device category; the first device category is a Jenkins packaging machine device. When the terminal device is a second terminal device and / or a third device, it is determined that the terminal device has a second device category; the second device category is the device corresponding to the project developer. The process of determining the binary build program required to execute the binary build instructions based on the device category of the terminal device includes: Trigger a third-party library management tool, and use the third-party library management tool to determine the device category of the terminal device based on the device identifier included in the binary build instructions; When the terminal device has a device category of the first device category, the binary build program required to execute the binary build instruction is determined to be the first build program; When the terminal device has a device category of the second device category, the binary build program required to execute the binary build instructions is determined to be the second build program.

9. The method for constructing source code according to claim 8, characterized in that, Based on the first build program and the pre-set compilation tools, the compilation and build of the source code corresponding to the Pod library that needs to be updated is executed, resulting in the build artifacts of the Pod library that needs to be updated, including: Based on the preset compilation tool, the source code to be processed corresponding to the Pod library that needs to be updated is compiled and built to obtain the build product of the Pod library that needs to be updated; wherein, the build product includes one or more of the following: static library, static library information, and changes to project linking conditions.

10. The method for constructing source code according to claim 8, characterized in that, Based on the second build program and the preset compilation tools, the compilation and build of the source code corresponding to the Pod library that needs to be updated is executed, resulting in the build artifacts of the Pod library that needs to be updated, including: Retrieve the keywords of the Pod library that the declaration indicates needs to be updated; If the keyword of the Pod library that needs to be updated is the first keyword category, then parse the binary option of the Pod library that needs to be updated; If the Pod library to be updated does not have a binary option, then the Pod library to be updated is imported in source code form. If the Pod library to be updated has a binary option, then the Pod library to be updated is imported in binary form. Based on the preset compilation tools, the compiler executes the compilation and build of the source code corresponding to the Pod library that needs to be updated, and obtains the build artifact of the Pod library that needs to be updated.

11. The method for constructing source code according to claim 10, characterized in that, The method for constructing the source code also includes: If the keyword of the Pod library that needs to be updated is the second keyword category, then analyze the changes between the current attribute file and the historical attribute file of the Pod library that needs to be updated; If there are changes, stop executing the binary conversion instructions; if there are no changes, determine whether the Pod library to be updated needs to be rebuilt using binary conversion. If a re-binary build is required, the execution of the binary build instruction is stopped; otherwise, the Pod update instruction corresponding to the Pod module name that needs to be binary-built is executed to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binary-built. Based on the preset compilation tool, the source code to be processed corresponding to the Pod library that needs to be updated is compiled and built to obtain the build product of the Pod library that needs to be updated.

12. A source code construction apparatus, characterized in that, The source code building apparatus, configured on the Jenkins build machine, includes: The instruction parsing module is used to receive binary build instructions sent by the terminal device and parse the binary build instructions, which include the target project name, the target branch name, and the name of the Pod module to be binary-coded. The update instruction execution module is used to pull the source code to be processed according to the target project name and the target branch name, and execute the Pod update instruction corresponding to the Pod module name that needs to be binaryed, so as to obtain the Pod library that needs to be updated included in the Pod module name that needs to be binaryed; A binary build program determination module is used to determine the binary build program required to execute the binary build instructions based on the device category of the terminal device; The compilation and build module is used to compile and build the source code corresponding to the Pod library to be updated based on the binary build program and the preset compilation tools, so as to obtain the build product of the Pod library to be updated.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for constructing the source code according to any one of claims 1-11.

14. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of constructing the source code according to any one of claims 1-11 by executing the executable instructions.

Images