一种编译集成方法及装置与流程

本申请涉及软件开发技术领域，特别涉及一种编译集成方法、装置、计算机设备及存储介质。

背景技术：

随着自动驾驶/辅助驾驶技术不断变革，车载电子系统的智能化和复杂度程度不断增加。为应对不同系统日益增加的算力需求和不同产品组合需求，各种以功能划分的组件和系统被不断的引入。例如，对于车载信息娱乐系统(in-vehicleinfotainment，ivi)(也可以称为“车机系统”)，通过集成linux系统到车机系统以提高系统的启动响应速度，使车机系统从开机到达可用状态的时间花费很短，通过集成android系统以丰富车机系统的应用生态，使得车机系统融合到android生态环境中，提高车机系统的娱乐性和可扩展性。此外，为应对车机系统的高度实时环境需求，很多实时操作系统(如free-rtos等)通常也需要被集成到车机系统中，例如音频处理系统和网络数据处理系统等。甚至，对于物理多核soc(片上系统)，不同的物理核心上需要同时运行多种功能系统。

然而，随着多个系统共存需求被不断提出，集成多种系统到车机系统的现有方案却存在不少的问题和不便。对于不同的系统及系统内部应用的开发，编译和打包通常都是分开进行，即采用不同的编译和集成框架分别完成各自组件和系统的编译，最后再整合打包，形成完整的系统。而对于系统内部应用以及系统的编译集成过程则是通过直接编写依赖关系文件的形式进行，这样不仅繁琐、易于出错，还不利于扩展新的平台，对产品组合策略也存在极大的限制。

因此，亟需提出一种新的编译集成方案，以解决上述问题。

技术实现要素：

为了解决现有技术的问题，本申请实施例提供了一种编译集成方法、装置、计算机设备以及存储介质，适用的编译语言包括但不限于c语言、c++等，以克服现有技术中存在的融合多个子系统的系统的编译集成方案过程繁琐、分散、可扩展性差以及模块复用程度低等问题。

为解决上述一个或多个技术问题，本申请采用的技术方案是：

第一方面，提供了一种编译集成方法，应用于编译集成框架，该编译集成框架支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，其中，所述一个产品为目标产品或所述至少两个产品包括目标产品，该方法包括如下步骤：

获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

进一步的，所述获取所述目标产品的配置文件，可以包括：

确定所述目标产品包含的所有系统、以及所述所有系统中的每个系统包含的一个或多个应用；

采用预设的语言定义所述所有系统中的每个系统的所述一个或多个应用的功能描述和依赖关系，生成所述目标产品的配置文件。

进一步的，所述根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块，可以包括：

根据所述每个系统的依赖关系确定所述每个系统所包含的一个或多个应用，以及所述一个或多个应用所包含的一个或多个组件；

从所述源代码仓库获取所述每个系统所包含的所述一个或多个组件对应的源代码模块。

进一步的，在利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译前，所述方法还可以包括：

获取所述每个系统的系统类型，根据所述系统类型查询是否存在所述每个系统对应的编译工具，若不存在，则根据所述系统类型配置所述每个系统对应的编译工具。

进一步的，在利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译前，所述方法还可以包括：

查询本地或远端服务器是否存在所述每个系统的编译文件，若存在，则获取所述每个系统的编译文件，否则，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件。

进一步的，所述根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件可以包括：

对所述至少两个系统中的所有系统的编译文件进行去重处理，将去重后的所述至少两个系统中的所有系统的编译文件打包生成所述目标产品的镜像文件。

进一步的，在根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件后，所述方法还可以包括：

获取并解析所述镜像文件的测试文件，根据解析结果从所述源代码仓库获取对应的测试代码；

在预设的测试环境中编译并执行所述测试代码生成测试结果；

根据所述测试结果生成测试报告。

进一步的，所述目标产品可以包括以下各项中的至少一项：车载信息娱乐系统、用于车辆通讯功能的智能网联系统(smartbox系统)、电池管理系统(batterymanagementsystem，bms)以及物理多核片上系统(system-on-a-chip，soc)的不同物理核心上需要同时运行多种功能的系统。

进一步的，所述配置文件可以包括yaml格式的配置文件。

第二方面，提供了一种编译集成装置，所述编译集成装置支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，其中，所述一个产品为目标产品或所述至少两个产品包括目标产品，所述装置包括：

文件获取模块，用于获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

文件解析模块，用于对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

代码获取模块，用于根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

代码编译模块，用于利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

系统生成模块，用于根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

第三方面，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下步骤：

获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如下步骤：

获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

本申请实施例提供的技术方案带来的有益效果是：

本申请实施例提供的系统的编译集成方法、装置、计算机设备及存储介质，应用于编译集成框架，所述编译集成框架支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，其中，所述一个产品为目标产品或所述至少两个产品包括目标产品，所述方法通过获取所述目标产品的配置文件，所述目标产品包括至少两个系统，对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系，根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件，根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件，通过简单的设计不同子系统的依赖关系，实现不同子系统的快速编译和构建过程，并实现了基于不同的平台开发的子系统同时编译和集成，提高系统的构建效率，简化了融合多个子系统的目标系统的编译集成过程，避免重复构建工作。

附图说明

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

图1是本申请实施例提供的编译集成框架的架构图；

图2是本申请实施例提供的通过编译集成框架实现对目标产品进行编译集成的流程图；

图3是本申请实施例提供的yaml格式的配置文件的示意图；

图4是本申请实施例提供的描述依赖关系的yaml语法表达方式的示意图；

图5是本申请实施例提供的将yaml格式的配置文件解析为依赖关系的示意图；

图6是本申请实施例提供的根据依赖关系编译生成编译文件的示意图；

图7是本申请实施例提供的通过编译集成框架实现对目标产品进行测试的流程图；

图8是本申请实施例提供的yaml格式的测试文件的示意图；

图9是本申请实施例提供的编译集成方法的流程图；

图10是本申请实施例提供的编译集成装置的结构示意图；

图11是本申请实施例提供的计算机设备的内部结构示意图。

具体实施方式

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

如背景技术所述，对于多个子系统共存的系统，例如，同时支持android和linux两个操作系统的车载娱乐系统(下称多系统车机)，需要先分别构建不同子系统的编译产物，然后再打包集成到一起。一方面，在当前多个操作系统共存的车机系统构建需求下，传统的逐个编译构建再集成打包的方式愈加难以满足软件快速开发集成的要求。另一方面，对于面向不同市场需求而制定的多种产品策略的产品编译集成需求，现有技术中的集成方法存在难以灵活组合产品组件的弊端。考虑到多个项目同时推进开发的场景，且多个平台存在灵活组合搭配的需求的情况，采用现有的编译构建工具实难满足要求。

为解决上述问题，本申请实施例中创造性的提出了一种编译集成方法，应用于编译集成框架，可以适用于c语言、c++或其他编译语言，通过简单的设计不同系统的依赖关系，实现不同系统的快速编译和构建过程，并实现了基于不同的平台开发的系统同时编译和集成，提高系统的构建效率，简化了融合多个系统的目标产品的编译集成过程，避免重复构建工作。

下面将结合附图和各个实施例，对本申请的方案进行详细介绍。

实施例一

为实现上述方法，本申请实施例中提供了一种编译集成框架，该编译集成框架支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，参照图1所示，该平台作如下部署：

菜单配置模块，用于组合定制不同系统产品或者定制包含不同组件的系统产品，通过建立不同菜单配置文件的方式，实现框架内多个项目或多个产品的并行开发、编译和集成，这里需要说明的是，本申请实施例中，菜单配置模块不仅可以用于定义产品的依赖关系，还可以用于定义产品测试时的依赖关系；

编译集成环境支持模块，本申请实施例中的编译集成环境支持模块基于bobbuildtool编译集成框架和buildenv编译环境配置模块来实现。具体实施时，可以使用python和yaml语言编写，为框架系统yaml菜单配置文件解析转换工具，为组件或者系统编译构建提供基础平台，提供安全的沙箱模式实现多种编译环境配置和同存；

代码同步模块，用于实现远端代码仓库服务器和本地代码同步，可以支持多人同时开发，其中同步方式包括但不限于git、svn等方式。代码同步模块还用于对菜单配置模块生成的文件进行版本管理，简单通过分支策略实现产品组合设计；

源代码模块，用于管理菜单配置模块配置的产品或者组件的源代码仓库；

编译链工具模块，用于管理针对不同产品硬件平台定制的编译工具链(也称编译工具)。由bobbuildtool模块和buildenv模块配置编译沙箱环境，源代码在编译工具链的作用下，生成正对特定系统平台的编译过程产物(即编译文件)，包括但不限于头文件、动态链接或者静态链接的库文件、可执行的程序文件以及配置文件等；

测试配置模块，用于基于菜单配置模块定义的不同测试范畴和方法执行不同测试动作，支持多种的测试手段，可以保证持续构建的质量和产品持续交互能力。例如，当需要针对源代码函数进行单元测试时，则通过菜单配置模块配置单元测试菜单配置文件，所述单元测试菜单配置文件定义了依赖的测试框架(如cppunit或者gtest&gmock等)，通过bobbuildtool模块和buildenv模块配置测试沙箱环境，测试配置模块会在该沙箱环境中对执行代码单元的测试用例，生成特定的测试报告；

编译产物同步模块，用于查询远端ci/cd集成服务器是否存在相同构建产物以及上传本地已构建的而远端ci/cd集成服务器没有完成构建的目标产物。

具体的，如图2所示，通过上述编译集成框架实现对目标产品进行编译集成的过程包括如下步骤：

s110：根据用户需求按照预设格式生成目标产品的配置文件；

具体的，这里的配置文件主要用于定义待生成的目标产品的功能描述和依赖关系。具体实施时，首先获取用户需求，在用户的需求基础上，设计用户的产品方案，包括但不限于按照要求设计产品基于的系统平台、产品的功能模块以及产品的版本划分等等，这里的产品指待生成的目标产品。然后按照已经设计好的产品方案，对产品按照功能模块进行划分，以预设格式的配置文件定义出每个功能模块的描述和依赖关系，按照每个产品版本的功能明细，以预设格式的配置文件定义出每个版本产品的描述和依赖关系等。

具体的，作为一种较优的示例，本申请实施例中的预设格式包括但不限于yaml格式。在以yaml格式生成目标产品的配置文件时，利用yaml文件依赖关系树构成一个完整产品(即目标产品)包含的yaml列表及相互关系描述。假设某目标产品至少包括2个不同的系统，每个系统又包括两个不同的应用，每个应用又由若干个组件搭建而成，其相互间的依赖关系可由如图3所示的yaml文件依赖关系树描述出来。建立以yaml文件编译的菜单目录管理系统内部或者系统间的依赖关系，以及建立以目标产物目录和中间产物目录不同文件夹，隔离中间产物，可以使目标构建产物清晰明了。并且以yaml文件定义系统组件和依赖关系，依赖关系简单，通过自定义模块的yaml文件，实现自定义编译模块范围，通过自定义不同系统的yaml文件，即可实现不同产品分支构建，适应于面向多客户和多市场的个性化产品配置需求。

yaml文件格式是一种便于读写的跨浏览器的语言格式，广泛应用于网络应用编程中，类似于json，也被广泛用做配置文件等。由于该语言格式应用广泛，支持该语言格式的编辑器和解析工具也十分丰富。本申请实施例提供的菜单配置模块生成的配置文件就是基于yaml文件格式的，通过在yaml文件中定义不同系统或者系统组件间的依赖关系，实现不同系统及内部组件的组合定义，从而实现不同产品组合。图4为通常描述依赖关系的yaml语法表达方式的示意图，图4中描述了产品a的部分依赖关系，图4示出部分表示产品a包括系统a和系统b，而系统a又包括功能模块a、b和c，系统b又包括功能模块a、c和e。

进一步参照图3所示，不同系统下的组件可能是相同的，例如系统1的应用1依赖的组件1、组件2和系统1的应用2依赖的组件1、组件2是相同的模块。本申请实施例中，同一系统下共享的组件，可以只编译一次就可以被不同的应用多次共享，从而提高编译的效率以及代码的复用率。也就是说，系统1下共享的组件1和组件2，可以只编译一次就可以被应用1和应用2多次共享。而不同系统之间的组件编译，由于不同系统依赖的编译工具链不同，因而无法实现一次编译，多个系统间共享。

s120：对所述配置文件进行解析，获取目标产品的依赖关系。

具体的，完成了目标产品的依赖关系描述定义之后，通过编译集成框架的yaml解析模块，将不同产品的yaml依赖关系树解析成不同系统、应用和组件的cmakelist/makefile/mk/bp等文件依赖关系树，该cmakelist/makefile/mk/bp等文件依赖关系树为可以指导编译的文件，如图5所示。

s130：根据目标产品的依赖关系获取对应的源代码模块，采用对应的编译工具进行编译打包，生成目标产品的镜像文件。

具体的，不同类型的系统需要使用不同的编译工具进行编译，本申请中可以预先在编译链配置模块配置定义针对各个类型系统使用的编译工具。具体进行编译时，首先根据依赖关系通过代码同步模块从代码仓库获取对应的源代码模块，然后调用各个系统对应的编译工具分别进行编译，将生成的编译文件打包，最终生成目标产品的镜像文件，如图6所示。除此之外，本申请实施例中的编译工具还支持实时配置，当某个需要编译的系统查询不到对应的预设编译工具时，可以实时为该系统配置对应的编译工具。

镜像文件是指将特定的一系列文件按照一定的格式制作成单一的文件，以方便用户下载和使用，例如一个操作系统、游戏等。它最重要的特点是可以被特定的软件识别并可直接刻录到光盘上。其实通常意义上的镜像文件可以再扩展一下，在镜像文件中可以包含更多的信息。比如说系统文件、引导文件、分区表信息等，这样镜像文件就可以包含一个分区甚至是一块硬盘的所有信息。而通常意义上的刻录软件都可以直接将支持的镜像文件所包含的内容刻录到光盘上。

为了便于理解本申请上述实施例的方案，以下举例说明本申请的编译集成过程：

假设需要开发的目标产品为一款同时集成android和linux系统的车机系统，采用hypervisor技术实现主机虚拟化，同时运行两个操作系统。采用本申请实施例提供的方案，只需要分别定义一个根菜单配置文件，在依赖项中，同时加入android系统和linux系统的菜单配置，此外，还可以在android系统和linux系统的根菜单配置文件中分别加入不同的系统组件或应用依赖，从而分别构建成两个完整的android系统和linux系统。也就是说，本申请通过yaml格式的菜单文件构建依赖关系树，然后通过解析关系依赖树，在bobbuildtool和buildenv构建的yaml解析模块翻译cmakelist.txt/makefle/mk/bp文件依赖关系，其中android系统采用mk/bp配置文件方式进行编译，再通过不同系统配置菜单文件中依赖的不同的编译工具链的配置，在不同的编译工具链下生成不同平台的目标产物，最后完成产物打包过程形成一个完整的系统镜像文件。

在完成上述编译集成过程之后，本申请还可以通过上述编译集成框架对目标产品进行测试。具体的，如图7所示，通过上述编译集成框架实现对目标产品进行测试的过程包括如下步骤：

s210：根据测试需求按照预设格式生成目标产品的测试文件；

具体的，本申请提供的系统编译集成框架还可以实现对构建的目标产品进行不同维度的测试。用户可以通过菜单配置模块编写不同的测试方案的测试文件实现多种维度测试。以yaml依赖关系树构建的配置文件为例，具体实施时，首先获取用户测试需求，根据用户的测试需求制定对应的测试方案，然后按照已经设计好的测试方案，生成对应的yaml文件。

s220：通过测试配置模块根据测试文件调用相应的测试代码，在预设测试环境中编译并执行所述测试代码生成测试结果。

具体的，以单元测试方案为例，首先根据测试需求以及待测试系统中涉及的功能模块制定测试方案(yaml文件)，如图8所示，待测试产品为系统a，其包括功能模块a、b和c。在测试配置模块内解析以上测试方案，代码同步模块根据解析结果从代码仓库中获取不同功能模块对应的单元测试代码到本测试配置模块中，在编译环境配置模块预先构建的沙箱环境中编译单元测试代码并执行生成的测试代码用例产物，汇总不同测试用例的结果，最终生成单元测试报告。

实施例二

对应于上述实施例一，如图9所示，本申请提供了一种编译集成方法，应用于上述编译集成框架，该方法包括如下步骤：

s310：获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

s320：对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

s330：根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

s340：利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

s350：根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，所述获取所述目标产品的配置文件，可以包括：确定所述目标产品包含的所有系统、以及所述所有系统中的每个系统包含的一个或多个应用；采用预设的语言定义所述所有系统中的每个系统的所述一个或多个应用的功能描述和依赖关系，生成所述目标产品的配置文件。

具体的，目标产品可能包括多个系统，每个系统可能包括一个或多个应用，每个应用可能由一个或多个组件搭建而成，本申请中的依赖关系用于描述系统、应用以及组件之间的依赖关系，使目标系统的结构清晰明了。

作为一种较优的实施方式，本申请实施例中，所述根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块，可以包括：根据所述每个系统的依赖关系确定所述每个系统所包含的一个或多个应用，以及所述一个或多个应用所包含的一个或多个组件；从所述源代码仓库获取所述每个系统所包含的所述一个或多个组件对应的源代码模块。

具体的，本申请实施例中，可以针对每个组件预先编写对应的源代码模块，将其存储至源代码仓库中统一管理，使用时可以直接从源代码仓库调用。其中，源代码仓库可以部署在本地，也可以部署在远端服务器，还可以同时在本地和远端服务器均做部署。

作为一种较优的实施方式，本申请实施例中，在利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译前，所述方法还可以包括：获取所述每个系统的系统类型，根据所述系统类型查询是否存在所述每个系统对应的编译工具，若不存在，则根据所述系统类型配置所述每个系统对应的编译工具。

具体的，不同类型的系统所需要采用的编译工具也不同，本申请实施例中，支持多个编译平台可以共存。具体实施时，一方面可以预先针对各种类型的系统预配置相应的编译工具(也称编译环境)，包括但不限于配置交叉编译工具链和设置环境变量等。利用预设的编译工具可以实现不同系统的编译，实现多个编译工具共存，从而不需要在同一目标产品中集成多个系统时对系统分别进行编译、打包。另一方面，本申请实施例中，还支持实时配置编译各种类型的系统所需要的编译工具，在编译前，先根据系统类型查询是否存在对应的编译工具，若是不存在，则实时配置该系统类型所需要的编译工具。支持实时配置编译各种类型的系统所需要的编译工具，可以实现快速的引入新的系统对应的编译工具链，从而实现新系统平台编译打包，提高编译集成框架的扩展性。

作为一种较优的实施方式，本申请实施例中，在利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译前，所述方法还可以包括：查询本地或远端服务器是否存在所述每个系统的编译文件，若存在，则获取所述每个系统的编译文件，否则，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件。

具体的，本申请实施例中，采用增量式编译方式，提高系统构建效率。具体实施时，设置在本地和ci/cd服务器同步已构建的相同产物(即编译文件)，在编译过程中，通过生成编译文件的代码版本快照信息产物的hash值，为编译文件生成唯一标识，在编译前，通过该标识查询是否存在相同的已构建成功的编译文件，以减少重复编译工作，加快产品的编译构建进程，实现产品的快速迭代。

作为一种较优的实施方式，本申请实施例中，所述根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件，可以包括：对所述至少两个系统中的所有系统的编译文件进行去重处理，将去重后的所述至少两个系统中的所有系统的编译文件打包生成所述目标产品的镜像文件。

具体的，在每个子系统的编译文件生成后，可以进一步对编译文件进行优化处理，包括但不限于去重处理等。这里的去重主要指将每个子系统的编译文件中重复的代码去除，以减少文件大小，减轻存储压力。

作为一种较优的实施方式，本申请实施例中，在根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件后，所述方法还可以包括：获取并解析所述镜像文件的测试文件，根据解析结果从所述源代码仓库获取对应的测试代码；在预设的测试环境中编译并执行所述测试代码生成测试结果；根据所述测试结果生成测试报告。

具体的，本申请实施例可以满足不同的测试需求。对于开发人员，在完成功能或者模块开发任务后，编写单元测试用例，配置yaml依赖关系，即可完成功能或者模块的单元测试验证。对于系统性能测试和应用接口测试人员，配置接口测试的yaml文件，即可实现对应用的接口测试。

作为一种较优的实施方式，本申请实施例中，所述目标产品包括以下各项中的至少一项：车载信息娱乐系统、用于车辆通讯功能的智能网联系统、电池管理系统以及物理多核片上系统soc的不同物理核心上需要同时运行多种功能的系统。

具体的，本申请实施例中，目标产品包括但不限于集成多个系统的产品，如车载信息娱乐系统(in-vehicleinfotainment，ivi)、用于车辆通讯功能的智能网联系统(如smartbox系统)、电池管理系统(batterymanagementsystem，bms)以及物理多核片上系统(system-on-a-chip，soc)的不同物理核心上需要同时运行多种功能的系统等。

作为一种较优的实施方式，本申请实施例中，所述配置文件包括yaml格式的配置文件。

实施例三

对应于上述实施例一和二，本申请还提供了一种编译集成装置。图10是根据一示例性实施例示出的编译集成装置的结构示意图，参照图10所示，该装置支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，其中，所述一个产品为目标产品或所述至少两个产品包括目标产品，该装置包括：

文件获取模块，用于获取所述目标产品的配置文件，所述目标产品包括至少两个系统；

文件解析模块，用于对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；

代码获取模块，用于根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；

代码编译模块，用于利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；

系统生成模块，用于根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，所述文件获取模块具体用于：确定所述目标产品包含的所有系统、以及所述所有系统中的每个系统包含的一个或多个应用；采用预设的语言定义所述所有系统中的每个系统的所述一个或多个应用的功能描述和依赖关系，生成所述目标产品的配置文件。

作为一种较优的实施方式，本申请实施例中，所述代码获取模块包括：组件确定单元，用于根据所述每个系统的依赖关系确定所述每个系统所包含的一个或多个应用，以及所述一个或多个应用所包含的一个或多个组件；代码获取单元，用于从所述源代码仓库获取所述每个系统所包含的所述一个或多个组件对应的源代码模块。

作为一种较优的实施方式，本申请实施例中，所述装置还包括：工具确定模块，用于获取所述每个系统的系统类型，根据所述系统类型查询是否存在所述每个系统对应的编译工具，若不存在，则根据所述系统类型配置所述每个系统对应的编译工具。

作为一种较优的实施方式，本申请实施例中，所述装置还包括：文件查询模块，用于查询本地或远端服务器是否存在所述每个系统的编译文件，若存在，则获取所述每个系统的编译文件。

作为一种较优的实施方式，本申请实施例中，所述系统生成模块具体用于：对所述至少两个系统中的所有系统的编译文件进行去重处理，将去重后的所述至少两个系统中的所有系统的编译文件打包生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，所述装置还包括：系统测试模块，用于获取并解析所述镜像文件的测试文件，根据解析结果从所述源代码仓库获取对应的测试代码；在预设的测试环境中编译并执行所述测试代码生成测试结果；根据所述测试结果生成测试报告。

作为一种较优的实施方式，本申请实施例中，所述目标产品包括以下各项中的至少一项：车载信息娱乐系统、用于车辆通讯功能的智能网联系统、电池管理系统以及物理多核片上系统soc的不同物理核心上需要同时运行多种功能的系统。

作为一种较优的实施方式，本申请实施例中，所述配置文件包括yaml格式的配置文件。

实施例四

对应于上述实施例一至三，本申请还提供了一种计算机设备。图11是根据一示例性实施例示出的计算机设备的内部结构示意图，参照图11所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种执行计划的优化方法。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

作为一种较优的实施方式，本申请实施例中，计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：获取所述目标产品的配置文件，所述目标产品包括至少两个系统；对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：确定所述目标产品包含的所有系统、以及所述所有系统中的每个系统包含的一个或多个应用；采用预设的语言定义所述所有系统中的每个系统的所述一个或多个应用的功能描述和依赖关系，生成所述目标产品的配置文件。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：根据所述每个系统的依赖关系确定所述每个系统所包含的一个或多个应用，以及所述一个或多个应用所包含的一个或多个组件；从所述源代码仓库获取所述每个系统所包含的所述一个或多个组件对应的源代码模块。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：获取所述每个系统的系统类型，根据所述系统类型查询是否存在所述每个系统对应的编译工具，若不存在，则根据所述系统类型配置所述每个系统对应的编译工具。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：查询本地或远端服务器是否存在所述每个系统的编译文件，若存在，则获取所述每个系统的编译文件，否则，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：对所述至少两个系统中的所有系统的编译文件进行去重处理，将去重后的所述至少两个系统中的所有系统的编译文件打包生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，处理器执行计算机程序时还实现以下步骤：获取并解析所述镜像文件的测试文件，根据解析结果从所述源代码仓库获取对应的测试代码；在预设的测试环境中编译并执行所述测试代码生成测试结果；根据所述测试结果生成测试报告。

作为一种较优的实施方式，本申请实施例中，所述目标产品包括以下各项中的至少一项：车载信息娱乐系统、用于车辆通讯功能的智能网联系统、电池管理系统以及物理多核片上系统soc的不同物理核心上需要同时运行多种功能的系统。

作为一种较优的实施方式，本申请实施例中，所述配置文件包括yaml格式的配置文件。

实施例五

对应于上述实施例一至四，本申请实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如下步骤：获取所述目标产品的配置文件，所述目标产品包括至少两个系统；对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系；根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块；利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件；根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：确定所述目标产品包含的所有系统、以及所述所有系统中的每个系统包含的一个或多个应用；采用预设的语言定义所述所有系统中的每个系统的所述一个或多个应用的功能描述和依赖关系，生成所述目标产品的配置文件。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：根据所述每个系统的依赖关系确定所述每个系统所包含的一个或多个应用，以及所述一个或多个应用所包含的一个或多个组件；从所述源代码仓库获取所述每个系统所包含的所述一个或多个组件对应的源代码模块。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：获取所述每个系统的系统类型，根据所述系统类型查询是否存在所述每个系统对应的编译工具，若不存在，则根据所述系统类型配置所述每个系统对应的编译工具。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：查询本地或远端服务器是否存在所述每个系统的编译文件，若存在，则获取所述每个系统的编译文件，否则，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：对所述至少两个系统中的所有系统的编译文件进行去重处理，将去重后的所述至少两个系统中的所有系统的编译文件打包生成所述目标产品的镜像文件。

作为一种较优的实施方式，本申请实施例中，所述计算机程序被处理器执行时，还实现如下步骤：获取并解析所述镜像文件的测试文件，根据解析结果从所述源代码仓库获取对应的测试代码；在预设的测试环境中编译并执行所述测试代码生成测试结果；根据所述测试结果生成测试报告。

作为一种较优的实施方式，本申请实施例中，所述目标产品包括以下各项中的至少一项：车载信息娱乐系统、用于车辆通讯功能的智能网联系统、电池管理系统以及物理多核片上系统soc的不同物理核心上需要同时运行多种功能的系统。

作为一种较优的实施方式，本申请实施例中，所述配置文件包括yaml格式的配置文件。

综上所述，本申请实施例提供的技术方案带来的有益效果是：

本申请实施例提供的系统的编译集成方法、装置、计算机设备及存储介质，应用于编译集成框架，所述编译集成框架支持一个产品的不同系统的同步编译或者至少两个产品的同步编译，其中，所述一个产品为目标产品，所述至少两个产品包括目标产品，所述方法通过获取所述目标产品的配置文件，所述目标产品包括至少两个系统，对所述配置文件进行解析，获取所述至少两个系统中每个系统的依赖关系，根据所述每个系统的依赖关系从源代码仓库获取所述每个系统对应的源代码模块，利用与所述每个系统对应的编译工具分别对所述每个系统对应的源代码模块进行编译，生成所述每个系统的编译文件，根据所述至少两个系统中的所有系统的编译文件生成所述目标产品的镜像文件，通过简单的设计不同子系统的依赖关系，实现不同子系统的快速编译和构建过程，并实现了基于不同的平台开发的子系统同时编译和集成，提高系统的构建效率，简化了融合多个子系统的目标系统的编译集成过程，避免重复构建工作。

需要说明的是：上述实施例提供的编译集成装置在触发编译集成业务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的编译集成装置与编译集成方法实施例属于同一构思，即该装置是基于该编译集成方法的，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。