一种程序编译方法、装置、设备及存储介质

技术领域

本申请涉及前端程序编译技术领域，尤其涉及一种程序编译方法、装置、设备及存储介质。

背景技术

目前，部分大型三维图形(Three-Dimensional，3D)软件项目是采用编程语言Typescript开发的浏览器应用，在应用时需要将Typescripts编译成JavaScript，以能在浏览器端运行，由于3D软件往往涉及庞大的项目代码，一些大型3D软件项目的项目代码量更是超过300万行，其项目拆分后的插件库可能达到100多个，各个插件库之间又存在着依赖关系，即一个插件库的编译需要依赖与另一个插件库的编译结果。然而，大型3D软件项目的产品迭代周期频繁，项目变化较大，在项目更新迭代时需要对插件库进行编译，由于插件库之间的依赖关系复杂，导致在进行插件库的更新编译时，无法对插件库进行快速编译，完成产品、版本的迭代及发布。

为解决上述问题，现有方案通常会事先将各插件库的编译顺序进行编排，写到一个配置文件中，每次对插件库进行编译发布时，按照事先编排好的顺序进行编译。然而，在各插件库中存在新的依赖或新增加插件库时，现有方案则需要手动对编译顺序进行重新计算，存在编译效率低下的问题。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种程序编译方法、装置、设备及存储介质。

第一方面，本申请提供了一种程序编译方法，包括：

依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息；

依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库；

依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库；

依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序；

按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

可选的，所述依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库，包括：

针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，所述目标标识信息为所述编译结果库针对所述插件库记录的标识信息；

若所述目标提交记录标识信息与所述目标标识信息不匹配，则将所述目标提交记录标识信息对应的插件库确定为所述待编译库。

可选的，所述依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序，包括：

获取所述依赖库的配置文件信息；

基于所述待编译库的配置文件信息和所述依赖库的配置文件信息进行遍历处理，得到插件依赖信息；

基于所述插件依赖信息，确定所述编译顺序。

可选的，所述基于所述待编译库的配置文件信息和所述依赖库的配置文件信息进行遍历处理，得到插件依赖信息，包括：

从所述待编译库的配置文件信息中提取第一插件依赖信息；

从所述依赖库的配置文件信息提取第二插件依赖信息；

基于所述第一插件依赖信息和所述第二插件依赖信息进行插件库遍历处理，得到所述插件依赖信息。

可选的，基于所述插件依赖信息，确定所述编译顺序，包括：

基于插件依赖信息，确定各目标插件库的编译等级，所述目标插件库包含所述待编译库和所述依赖库；

基于所述待编译库的编译等级和所述依赖库的编译等级，确定所述编译顺序，其中，所述依赖库的编译等级高于所述待编译库的编译等级。

可选的，所述在判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配之前，还包括：

将所述目标程序的版本库作为所述编译结果库；

所述针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，包括：从所述编译结果库中，分别提取所述目标程序中每个插件库的目标标识信息；若插件库的目标标识信息与所述插件库对应的目标提交记录标识信息相同，则确定所述插件库对应的目标提交记录标识信息与目标标识信息相匹配；否则，确定所述插件库对应的目标提交记录标识信息与目标标识信息不匹配。

可选的，所述依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，包括：

获取用户针对目标程序提交的编译触发操作；

基于所述编译触发操作，获取目标程序对应的版本信息；

基于所述版本信息，确定所述编译结果库；

从所述编译结果库中，提取所述目标程序中各插件库对应的目标提交记录标识信息。

第二方面，本申请提供了一种程序编译装置，包括：

获取模块，用于依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息；

待编译库确定模块，用于依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库；

依赖库确定模块，用于依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库；

编译顺序确定模块，用于依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序；

编译结果确定模块，用于按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

第三方面，本申请提供了一种程序编译设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现如第一方面任一项实施例所述的程序编译方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项实施例所述的程序编译方法的步骤。

综上，本申请通过依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，依据各插件库对应的目标提交记录标识信息，确定目标程序的待编译库，依据待编译库的配置文件信息，确定待编译库对应的依赖库，依据依赖库的配置文件信息，确定待编译库和依赖库对应的编译顺序，按照编译顺序进行编译处理，得到目标程序对应的插件库编译结果，解决了现有方案在目标程序中各插件库中出现新的依赖或新增加插件库时，需要手动对编译顺序进行重新计算而导致的问题，提高了插件库编译效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种程序编译方法的流程示意图；

图2是本申请一个可选实施例提供的一种程序编译方法的步骤流程示意图；

图3是本申请实施例提供的一种依赖关系配置图；

图4为本申请实施例提供的一种程序编译装置的结构框图；

图5是本申请实施例提供的一种程序编译设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于对本申请实施例的理解，下面将结合附图以及具体实施例做进一步的解释说明，实施例并不构成对本申请实施例的限定。

图1为本申请实施例提供的一种程序编译方法的流程示意图，在具体实现中，本申请实施例提供的程序编译方法可以应用于各种前端程序的各个插件库中，实现对各插件库的高效编译。如图1所示，本申请实施例提供的程序编译方法具体可以包括如下步骤：

步骤110，依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息。

具体的，编译触发操作可以是开发人员或用户在需要对插件库进行编译时输入的编译操作，其可以是分布式版本控制系统(Git)操作指令，本申请实施例对此不做具体限制。具体而言，本申请实施例可以在需要对插件库进行编译操作时，通过编译触发操作，确定需要进行插件库编译操作的项目程序，以将该项目程序作为目标程序，随后可以获取该目标程序各插件库对应的目标提交记录标识信息，该目标提交记录标识信息可以用于确定插件库是否需要进行编译，以在确定插件库需要进行编译的情况下，将该插件库作为待编译插件库。

在具体实现中，本申请实施例可以将目标程序中的各个插件库预先存储至编译结果库中，该编译结果库可以是分布式版本控制系统(Git)仓库，本申请实施例对此不做具体限制。开发人员或针对目标程序中的插件库进行修改后，都可以将该修改后的插件库对应的编译结果及相关信息等上传至统一的编译结果Git仓库中。即开发人员针对某个插件库进行修改或编译后，可以将该修改或编译后的插件库上传至编译结果库，此时，Git仓库可以基于开发人员上传的修改或编译后的插件库，生成该插件库对应的最新提交记录编号，该最新提交记录编号可以作为目标提交记录标识信息，本申请实施例对目标提交记录标识信息不做具体限制。在后续处理中，可以依据各个插件库的目标提交记录标识信息，确定是否需要对该插件库进行编译操作，并可以在需要对插件库进行编译操作时，将该需要进行编译操作的插件库作为待编译库，即执行步骤120。

步骤120，依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库。

具体的，待编译库可以是指待编译插件库，即需要进行编译处理的插件库。本申请实施例在获取到目标提交记录标识信息后，可以通过目标提交记录标识，确定各插件库中需要进行编译处理的插件库，以将该需要进行编译处理的插件库作为目标程序的待编译库。

在具体实现中，Git仓库中可以存储目标程序中各插件库在上一次编译后生成的记录编号，在进行插件库编译时，可以将该目标程序中各插件库的最新提交记录编号与上一次编译生成的记录编号进行比对，判断最新提交记录编号是否与上一次编译生成的记录编号一致，进而根据判断结果，确定是否需要针对该插件库进行编译，将该插件库作为待编译库。具体而言，若最新提交记录编号与上一次编译生成的记录编号一致，则开发人员最新一次上传的插件库可能与Git仓库原先存储的插件库一样，该插件库可能没有重新修改或编译，因此，可以不对该插件库进行编译处理，当然，也可能是开发人员并未对针对该插件库进行重新上传，Git仓库中该插件库没有提交新的记录编号，因此，也可以不对该插件库进行编译处理；若最新提交记录编号与存储记录编号不一致，则可以确定开发人员最新一次上传的插件库经过修改或编译，需要对该插件库进行编译处理，因此，可以将该插件库作为待编译插件库。

在实际处理中，用户或开发人员可以通过预先编写好的一键自动触发程序对所有的Git仓库中的插件库进行遍历处理，统计出所有需要编译的插件库，以作为待编译库，在后续处理中可以针对每一个待编译库，确定该待编译库对应的依赖库。

步骤130，依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库。

具体的，依赖库可以是指在进行编译时需要依赖于待编译库的编译结果才能进行编译的插件库，本申请实施例对此不做具体限制。配置文件信息可以用于记录依赖于该待编译库的插件库信息，本申请实施例对此也不做具体限制。具体而言，本申请实施例在确定待编译库后，可以针对每一个待编译库，获取待编译库的配置文件信息，基于配置文件信息记录的依赖于待编译库的插件库信息，确定所有依赖于该待编译库的插件库，以作为依赖库。实现在对待编译库进行编译时，自动计算出每一个待编译库对应的依赖库，无需人工计算待编译库的依赖库，提高插件库编译效率。

步骤140，依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序。

具体的，本申请实施例在确定依赖于待编译库的依赖库后，可以获取每一个依赖库的配置文件信息，通过各个依赖库的配置文件信息，确定待编译库和依赖库的编译顺序。

在具体实现中，依赖库除了可以与待编译库之间存在依赖关系之外，依赖库与依赖库之间也可以存在依赖关系，对于即依赖于待编译库也依赖于其它依赖库的插件库，其编译结果不仅依赖于待编译库的编译结果，也依赖于其所依赖的依赖库的编译结果，其编译顺序可以排在待编译库和其所依赖的依赖库之后。具体而言，可以基于待编译库的配置文件信息和依赖库的配置文件信息进行遍历计算处理，得到待编译库与依赖库之间的依赖关系以及依赖库与依赖库之间的依赖关系，随后可以基于各依赖关系，通过算法，得到待编译库和依赖库的编译顺序，从而可以在出现插件库新增或插件库依赖修改时，能自动计算各插件库相应的编译顺序，无需手动编排编译顺序。

例如，现有插件库A、插件库B、插件库C以及插件库D，其中，插件库A为待编译库，插件库B、插件库C以及插件库D均为依赖于插件库A的依赖库，而插件库C以及插件库D可以即依赖于插件库A，又依赖于插件库B。可以通过算法，得出插件库A、插件库B、插件库C以及插件库D之间的编译顺序为，先编译插件库A，再编译插件库B，而对于插件库C和插件库D，由于插件库C和插件库D之间没有依赖关系，其编译顺序可以是随机，如在编译完插件库B后，编译插件库C，最后编译插件库D。

在具体实现中，对于不存在依赖关系的插件库，可以对这些不存在依赖关系的插件库执行并行编译，降低编译时长，最大限度加快编译速度。例如，对于插件库C和插件库D，插件库C和插件库D之间不存在依赖关系，因此，在依次对插件库A、插件库B进行顺序编译后，可以对插件库C和插件库D执行并行编译。实现在发布项目程序的迭代版本时，对于仅修改一个或几个插件库的项目程序，可以根据算法计算得到修改过的插件库和相关的被依赖的插件库，在进行编译发版时，仅需编译该修改过的插件库及其相关的依赖库，不需要编译所有的插件库，节省插件库编译时间。

步骤150，按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

具体的，本申请实施例在确定编译顺序后，可以基于编译顺序对待编译库和依赖库进行顺序编译，得到目标程序对应的插件库编译结果，其中，插件库编译结果可以分为插件库编译成功结果和插件库编译失败结果，本申请实施例对此不做具体限制。

可见，本申请实施例通过依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，依据各插件库对应的目标提交记录标识信息，确定目标程序的待编译库，依据待编译库的配置文件信息，确定待编译库对应的依赖库，依据依赖库的配置文件信息，确定待编译库和依赖库对应的编译顺序，按照编译顺序进行编译处理，得到目标程序对应的插件库编译结果，实现通过程序自动计算插件库的编译顺序，解决了现有方案在目标程序中各插件库中出现新的依赖或新增加插件库时，需要手动对编译顺序进行重新计算而导致的问题，提高了插件库编译效率。

参照图2，示出了本申请一个可选实施例提供的一种程序编译方法的步骤流程示意图。该程序编译方法可以具体可以包括如下步骤：

步骤210，依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息。

在一个可选实施例中，本申请实施例依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，具体可以包括：获取用户针对目标程序提交的编译触发操作；基于所述编译触发操作，获取目标程序对应的版本信息；基于所述版本信息，确定所述编译结果库；从所述编译结果库中，提取所述目标程序中各插件库对应的目标提交记录标识信息。具体而言，可以通过获取用户针对目标程序提交的编译触发操作，对该编译触发操作进行解析，得到目标程序对应的版本信息，当然，编译触发操作本身也可以携带有版本信息，以便可以从编译触发操作中快速提取版本信息。在确定目标程序对应的版本信息后，可以通过版本信息，确定存储目标程序的编译结果库，即Git仓库，进而可以从Git仓库中提取目标程序中各插件库对应的目标提交记录标识信息。

步骤220，针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配。

其中，所述目标标识信息为所述编译结果库针对所述插件库记录的标识信息。

具体的，本申请实施例在确定目标程序中各插件库后，可以针对每一个插件库，判断该插件库的目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，以便后续可以根据匹配结果判断是否需要对插件库进行编译处理。

在具体实现中，目标标识信息可以是插件库在上一次编译后生成的记录编号。具体而言，编译结果库针对目标程序各插件库进行编译发版后，可以生成该插件库对应的记录编号，并可以将该记录编号作为目标标识信息进行存储，在获取到目标提交记录标识信息后，可以将该目标记录标识信息对应的最新提交记录编号与目标标识信息对应的记录编号进行比对，判断两个记录编号是否一致，从而确定目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配。

在一个可选实施例中，本申请实施例在判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配之前，具体还可以包括：将所述目标程序的版本库作为所述编译结果库；所述针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，包括：从所述编译结果库中，分别提取所述目标程序中每个插件库的目标标识信息；若插件库的目标标识信息与所述插件库对应的目标提交记录标识信息相同，则确定所述插件库对应的目标提交记录标识信息与目标标识信息相匹配；否则，确定所述插件库对应的目标提交记录标识信息与目标标识信息不匹配。

步骤230，若所述目标提交记录标识信息与所述目标标识信息不匹配，则将所述目标提交记录标识信息对应的插件库确定为所述待编译库。

具体的，本申请实施例在确定目标提交记录标识信息和目标标识信息后，可以通过判断目标提交记录标识信息与目标标识信息是否匹配，进而确定是否将目标提交记录标识信息对应的插件库确定为待编译库。具体而言，若目标提交记录标识信息与目标标识信息不匹配，则可以将目标提交记录标识信息对应的插件库确定为待编译库；若目标提交记录信息与目标标识信息相匹配，则可以不将目标提交记录标识信息对应的插件库确定为待编译库。

作为本申请的一个示例，参照图3，图3为本申请提供的一种依赖配置图，该依赖配置图中可以包含3D软件项目程序的各个插件库及插件库的依赖关系。具体而言，该3D软件项目程序可以包含framework插件库、basic插件库、wall插件库、room插件库以及door插件库等五个插件库，这些插件库均可以存储到Git仓库，并可以通过插件库记录文件，如project-config.json记录所有插件库，其中，framework插件库可以是整个目标程序的框架结构库，用于提供3D引擎、网络请求及相关的算法能力，提供通用能力，不参与相关业务逻辑；basic插件库可以是基础库，用于提供所有模块通用对业务进行封装；wall插件库可以是墙业务模块，用于提供墙体结构服务能力；door插件库可以是门，是在墙体上的一种模型，是基于墙体衍生出来的一种业务；room插件库可以是房间服务，也是基于墙体的一个业务服务。若开发人员需要对framework插件库进行编译发版，则开发人员可以将编译后的framework插件库上传至Git仓库中，并可以通过预先编写好的一键编译程序触发一键编译，生成编译触发操作，以通过编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，根据framework插件库对应的目标提交记录标识信息，确定当前需要针对framework插件库进行编译处理，随后可以将framework插件库确定为待编译库，通过程序自动判断修改过的插件库，只需要编译修改过的插件库或代码库，而不需要编译所有插件库，在后续编译过程中，可以大大节省编译时间，提高编译速度。

步骤240，依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库。

在具体实现中，待编译库配置文件信息除了可以记录依赖于该待编译库的插件库信息外，还可以记录该待编译库所依赖的插件库信息，本申请实施例对此不做具体限制。具体而言，本申请实施例在获取到配置文件信息之后，可以判断配置文件信息中记录的是依赖于该待编译库的插件库信息，还是该待编译库所以依赖的插件库信息，若该配置文件信息中记录了依赖于该待编译库的插件库信息，则可以直接从配置文件信息中提取插件库信息，基于插件库信息，确定插件依赖信息，该插件依赖信息可以包含待编译库和各插件库之间的依赖关系，从而可以基于插件依赖信息进行遍历处理，得到待编译库对应的依赖库；若配置文件信息中记录的是该待编译库所依赖的插件库信息，则可以通过获取所有插件库对应的配置文件信息进行遍历处理，确定所有插件库之间的依赖关系，从而基于依赖关系，确定所有依赖于该待编译库的插件库，以将该插件库作为依赖库。通过配置文件信息，实现在对待编译库进行编译时，自动计算出每一个待编译库对应的依赖库，无需人工计算待编译库的依赖库，提高编译效率。

作为本申请一个示例，可以预先对目标程序中各插件库，生成该插件库的配置文件信息，如参照图3，可以针对framework插件库、basic插件库、wall插件库、room插件库以及door插件库等，预先为每一个插件库生成一份plugin.xml文件，以将该plugin.xml文件作为配置文件信息，其中，plugin.xml可以用于记录该插件库的名称、依赖于该插件库的其它插件库信息以及该插件库所依赖的其它插件库信息等，本申请实施例对此不做限制。在确定将framework插件库作为待编译插件库后，可以获取framework插件库的配置文件信息，即获取framework插件库的plugin.xml文件。随后，可以判断framework插件库的plugin.xml文件中记录的是依赖于framework插件库的插件库信息，还是framework插件库所依赖的插件库信息。若framework插件库的plugin.xml文件记录的是依赖于framework插件库的插件库信息，则可以直接从plugin.xml文件信息中提取插件库信息，基于插件库信息，确定插件依赖信息，该插件依赖信息可以包含待编译库和各插件库之间的依赖关系，如该依赖关系可以表示为：framework->{basic，wall，room，door}，随后可以通过依赖关系，确定依赖于framework插件库的依赖库，如可以将basic插件库、wall插件库、room插件库以及door插件库等作为framework插件库的依赖库。若framework插件库的plugin.xml文件记录的是framework插件库所依赖的插件库信息，则可以获取目标程序中各插件库的plugin.xml文件，通过对所有的plugin.xml文件进行遍历计算处理，得到插件依赖信息，该插件依赖信息也可以包含待编译库和各插件库之间的依赖关系，从而可以通过依赖关系，确定依赖于framework插件库的依赖库。

步骤250，获取所述依赖库的配置文件信息。

具体的，本申请实施例在确定待编译库的依赖库后，可以获取依赖库的配置文件信息。

例如，可以分别获取basic插件库、wall插件库、room插件库以及door插件库的plugin.xml文件。

步骤260，基于所述待编译库的配置文件信息和所述依赖库的配置文件信息进行遍历处理，得到插件依赖信息。

在具体实现中，本申请实施例在获取到待编译库的配置文件信息和依赖库的配置文件信息后，可以从待编译库的配置文件信息中提取待编译库与依赖库之间的插件依赖信息，并可以从依赖库的配置文件信息中提取依赖库与依赖库之间的插件依赖信息，随后可以基于待编译库与依赖库之间的插件依赖信息、依赖库与依赖库之间的插件依赖信息，确定插件依赖信息。

可选的，上述基于所述待编译库的配置文件信息和所述依赖库的配置文件信息进行遍历处理，得到插件依赖信息，具体可以包括以下子步骤：

子步骤2601，从所述待编译库的配置文件信息中提取第一插件依赖信息。

具体的，第一插件依赖信息可以包含待编译库和依赖库之间的依赖关系。

例如，参照图3，可以基于framework插件库的配置文件信息，得到framework插件库的依赖库为basic插件库、wall插件库、room插件库以及door插件库，第一插件依赖信息可以为：framework->{basic,wall,room,door}。

子步骤2602，从所述依赖库的配置文件信息提取第二插件依赖信息。

具体的，第二插件依赖关系可以包含依赖库之间的依赖关系。

例如，参照图3，对于basic插件库、wall插件库、room插件库以及door插件库，wall插件库、room插件库以及door插件库均可以依赖于basic插件库，room插件库和door插件库又可以依赖于wall插件库，因此，第二插件依赖关系可以包含baisc->{wall,room,door}和wall->{room,door}。

子步骤2603，基于所述第一插件依赖信息和所述第二插件依赖信息进行插件库遍历处理，得到所述插件依赖信息。

具体的，本申请实施例在确定第一插件依赖信息和第二插件依赖信息后，可以基于第一插件依赖信息和第二插件依赖信息进行插件库遍历处理，确定待编译库和依赖库之间所有依赖关系以及依赖库和依赖库之间的所有依赖关系，得到插件依赖信息。

例如，参照图3插件依赖信息可以包括

framework->{basic,wall,room,door}、baisc->{wall,room,door}和wall->{room,door}。

步骤270，基于所述插件依赖信息，确定所述编译顺序。

具体的，本申请实施例在确定插件依赖信息后，可以基于插件依赖信息，确定待编译库和依赖库的编译顺序。具体而言，可以先对待编译库进行编译处理，在完成对待编译库的编译后，可以基于依赖库之间的依赖关系对依赖库执行顺序编译，对于没有依赖关系的依赖库，则可以执行并行编译，以加快编译速度，提供插件库的编译效率。

例如，参照图3，可以先对framework插件库进行编译，再framework完成编译后，可以对仅依赖于framework插件库的basic插件库进行编译，完成basic插件库的编译后，可以对依赖于framework插件库和basic插件库的wall插件库进行编译，最后，对于room插件库和door插件库，由于二者之间没有依赖关系，因此可以对room插件库和door插件库执行并行编译。

可选的，本申请实施例基于所述插件依赖信息，确定所述编译顺序，具体可以包括以下子步骤：

子步骤2701，基于插件依赖信息，确定各目标插件库的编译等级，所述目标插件库包含所述待编译库和所述依赖库。

在具体实现中，获取到插件依赖信息后，可以基于插件依赖信息确定目标插件库的编译等级。具体而言，可以为每一个目标插件库预设一个初始编译等级，根据待编译库和依赖库之间的依赖关系以及依赖库与依赖库之间的依赖关系，对待编译库和依赖库的编译等级进行调整，得到编译等级，后续可以基于目标插件库的编译等级，确定编译顺序。

例如，以图3中各插件库为例，图3中各插件库可以作为目标插件库，可以为目标插件库初始化一张二维数组，该二维数组可以包含每一个目标插件库的插件库名称(pluginName)以及目标插件库的初始编译等级(level)。具体而言，其生成的二维数组可以是：[{“pluginName”:“framework”，

“level”:0},{“pluginName”:“basic”,“level”:0}，{“pluginName”:“wall”，“level”:0}，{“pluginName”:“room”，“level”:0}，{“pluginName”:“door”，“level”:0}]，在确定目标插件库的二维数组后，可以编译该二维数组中的每一个目标插件库，确定目标插件库中的待编译库和依赖库，对于依赖于待编译库的依赖库，判断依赖库的level是否小于待编译库的level+1，如果是小于，则将该依赖库的level设置为待编译库的level+1，可以得到framework插件库的level为0，basic插件库的level为1，wall插件库的level为1，room插件库的level为1，door插件库的level为1，即第一次遍历后的二维数组为[{“pluginName”:“framework”，“level”:0},{“pluginName”:“basic”,“level”:1}，{“pluginName”:“wall”，“level”:1}，{“pluginName”:“room”，“level”:1}，{“pluginName”:“door”，“level”:1}]。随后可以基于依赖库之间的依赖关系，判断依赖于其它插件库的依赖库的level是否小于被依赖的依赖库的level+1，如对于依赖关系

baisc->{wall,room,door}，可以判断wall插件库的level是否小于baisc插件库的level+1，若小于，则将wall插件库的level设置为basic插件库的level+1，即wall插件库的level为2，同理，对room插件库和door插件库进行level判断，可以得到room插件库的level为2，door插件库的level为2，从而可以得到第二次遍历后的二维数组：[{“pluginName”:“framework”，

“level”:0},{“pluginName”:“basic”,“level”:1}，{“pluginName”:“wall”，“level”:2}，{“pluginName”:“room”，“level”:2}，{“pluginName”:“door”，“level”:2}]。又如，对于依赖关系：wall->{room,door}，可以判断room插件库的level是否小于wall插件库的level+1，若小于，则将room插件库的level设置为room插件库的level+1，即room插件库的level为3，同理，对door插件库进行level判断可以得到door插件库的level为3，从而可以得到第三次遍历后的二维数组：[{“pluginName”:“framework”，

“level”:0},{“pluginName”:“basic”,“level”:1}，{“pluginName”:“wall”，“level”:2}，{“pluginName”:“room”，“level”:3}，{“pluginName”:“door”，“level”:3}]。

子步骤2702，基于所述待编译库的编译等级和所述依赖库的编译等级，确定所述编译顺序。

其中，所述依赖库的编译等级高于所述待编译库的编译等级

具体的，本申请实施例在确定待编译库和依赖库的编译等级后，可以基于编译等级由小到大，对待编译库和依赖库进行编译排序，得到编译顺序。

在具体实现中，可能出现依赖库之间的编译等级相同的情况，对于编译等级相同的依赖库，可以进行并行编译，以快速完成插件库编译。

例如，基于二维数组[{“pluginName”:“framework”，

“level”:0},{“pluginName”:“basic”,“level”:1}，{“pluginName”:“wall”，“level”:2}，{“pluginName”:“room”，“level”:3}，{“pluginName”:“door”，“level”:3}]，可以确定framework插件库的level为0、basic插件库的level为1、wall插件库的level为2、room插件库的level为3以及door插件库的level为3，随后可以根据各插件库的level进行由小到大的排序，得到编译顺序，该编译顺序可以是：framework->basic->wall->room-door。

步骤280，按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

例如，对于编译顺序framework->basic->wall->room-door，可以按照编译顺序对待编译库和依赖库进行编译处理，并可以得到目标程序对应的插件编译结果。

在具体实现中，插件库编译结果可以分为插件库编译成功结果和插件库编译失败结果，本申请实施例得到插件库编译结果后，可以将该插件库编译结果向用户或开发人员进行展示，使得用户或开发人员可以实时了解插件库编译的编译情况，在插件库编译失败时，能及时处理。

综上，本申请实施例通过获取用户针对目标程序提交的编译触发操作，依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息，通过每一个插件库的目标提交记录标识信息和目标标识信息，确定待编译库，进而根据待编译库的配置文件信息，确定待编译库对应的依赖库，基于待编译库的配置文件信息和依赖库的配置文件信息进行遍历处理，得到插件依赖信息，基于插件依赖信息，确定编译顺序，从而可以按照编译顺序对待编译库和依赖库进行编译处理，得到编译结果，解决了现有方案在目标程序中各插件库中出现新的依赖或新增加插件库时，需要手动对编译顺序进行重新计算而导致的问题，实现了仅对修改过的插件库进行编译，而不需要编译所有的库，节省插件库编译时间，提高了插件库编译效率。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。

如图4所示，本申请实施例还提供了一种程序编译装置400，包括：

获取模块410，用于依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息；

待编译库确定模块420，用于依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库；

依赖库确定模块430，用于依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库；

编译顺序确定模块440，用于依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序；

编译结果确定模块450，用于按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

可选的，所述待编译库确定模块，包括：

判断子模块，用于针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，所述目标标识信息为所述编译结果库针对所述插件库记录的标识信息；

待编译库确定子模块，用于在所述目标提交记录标识信息与所述目标标识信息不匹配时，将所述目标提交记录标识信息对应的插件库确定为所述待编译库。

可选的，所述编译顺序确定模块，包括：

配置文件信息获取子模块，用于获取所述依赖库的配置文件信息；

插件依赖信息确定子模块，用于基于所述待编译库的配置文件信息和所述依赖库的配置文件信息进行遍历处理，得到插件依赖信息；

编译顺序确定子模块，用于基于所述插件依赖信息，确定所述编译顺序。

可选的，所述插件依赖信息确定子模块，包括：

第一插件依赖信息提取单元，用于从所述待编译库的配置文件信息中提取第一插件依赖信息；

第二插件依赖信息提取单元，用于从所述依赖库的配置文件信息提取第二插件依赖信息；

基于所述第一插件依赖信息和所述第二插件依赖信息进行插件库遍历处理，得到所述插件依赖信息。

可选的，所述编译顺序确定子模块，包括：

编译等级确定单元，用于基于插件依赖信息，确定各目标插件库的编译等级，所述目标插件库包含所述待编译库和所述依赖库；

编译顺序确定单元，用于基于所述待编译库的编译等级和所述依赖库的编译等级，确定所述编译顺序，其中，所述依赖库的编译等级高于所述待编译库的编译等级。

可选的，还包括：

编译结果库确定模块，用于将所述目标程序的版本库作为所述编译结果库；

所述针对每一个插件库，判断所述目标提交记录标识信息是否与编译结果库中的目标标识信息相匹配，包括：从所述编译结果库中，分别提取所述目标程序中每个插件库的目标标识信息；若插件库的目标标识信息与所述插件库对应的目标提交记录标识信息相同，则确定所述插件库对应的目标提交记录标识信息与目标标识信息相匹配；否则，确定所述插件库对应的目标提交记录标识信息与目标标识信息不匹配。

可选的，所述获取模块，包括：

编译触发操作获取子模块，用于获取用户针对目标程序提交的编译触发操作；

版本信息获取子模块，用于基于所述编译触发操作，获取目标程序对应的版本信息；

编译结果库确定子模块，用于基于所述版本信息，确定所述编译结果库；

目标提交记录标识信息提取子模块，用于从所述编译结果库中，提取所述目标程序中各插件库对应的目标提交记录标识信息。

需要说明的是，本申请实施例提供的程序编译装置可执行本申请任意实施例所提供的程序编译方法，具备执行程序编译方法相应的功能和有益效果。

在具体实现中，上述程序编译装置可以集成在设备中，使得该设备可以依据获取到的目标提交记录标识信息，确定待编译库，进而基于待编译库的配置文件信息确定依赖库，依据依赖库的配置文件信息确定编译顺序，从而根据编译顺序对待编译库和依赖库进行编译，以作为程序编译设备，实现对目标程序中各个插件库的编译。该程序编译设备可以是由两个或多个物理实体构成，也可以是一个物理实体构成，如程序编译设备可以是个人计算机(Personal Computer，PC)、电脑、服务器等，本申请实施例对此不作具体限制。

如图5所示，本申请实施例提供提供了一种程序编译设备，包括处理器111、通信接口112、存储器113和通信总线114，其中，处理器111，通信接口112，存储器113通过通信总线114完成相互间的通信；存储器113，用于存放计算机程序；处理器111，用于执行存储器113上所存放的程序时，实现前述任意一个方法实施例提供的程序编译方法的步骤。示例性的，程序编译方法的步骤可以包括如下步骤：依据编译触发操作，获取目标程序中各插件库对应的目标提交记录标识信息；依据所述各插件库对应的目标提交记录标识信息，确定所述目标程序的待编译库；依据所述待编译库的配置文件信息，确定所述待编译库对应的依赖库；依据所述依赖库的配置文件信息，确定所述待编译库和所述依赖库对应的编译顺序；按照所述编译顺序进行编译处理，得到所述目标程序对应的插件库编译结果。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述任意一个方法实施例提供的程序编译方法的步骤。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。