CN107608677A - 一种编译处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供一种编译处理方法、装置及电子设备，对于大型项目划分成的多个模块对应的多个源代码文件，通过获得这多个源代码文件包含的预编译指令，从而据此获得这多个源代码文件存在的直接依赖关系和间接依赖关系，之后，筛选出使这多个源代码文件中存在的依赖关系数量变动最多的直接依赖关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删除，再采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码文件。可见，本申请通过减少多个源代码文件存在的依赖关系，从根源上达到了提高项目整体编译速度的效果，同时减少了开发中重编译情况出现的几率，减少了开发人员的工作量，缩短了整个项目的构建时间。

Description

一种编译处理方法、装置及电子设备

技术领域

本申请涉及项目编译应用领域，具体涉及一种编译处理方法、装置及电 子设备。

背景技术

C++是C语言的继承，既可以进行C语言的过程化程序设计，又可以进行 抽象数据类型为特点的基于对象的程序设计，还可以进行以继承和多态为特 点的面向对象的程序设计。可见，C++同时兼具面向底层和面向对象两方面的 属性，使其成为大型项目(如大型游戏项目)的首选开发语言。

在实际应用中，一个大型项目通常不会作为一个整体工程进行编译，而 是将大型项目划分成多个模块，不同模块可以以静态库或动态库的方式进行 组织，并分别对各模块进行编译以及测试，这样，多个开发人员协作可以并 行开发一个大型项目，提高项目开发效率。

目前，随着用户对大型项目的功能要求越来越多，大型项目的模块以及 代码数量将不断增加，然而，由于大型项目中的各模块之间错综复杂的依赖 关系，在进行各模块的编译以及测试时，需要相应开发人员相互沟通并配合， 才能保证大型项目的可靠开发，这样就会经常出现“一次改动，整体重编” 的情况，不仅增大了开发人员的工作量，且使得整个项目构建时间过长，从 而无法满足产品快速迭代的需求。

发明内容

有鉴于此，本申请实施例提供一种编译处理方法、装置及电子设备，从 根源上提高了整个项目编译速度，同时减少了开发中重编译情况出现的几率， 减少了开发人员的工作量，缩短了整个项目的构建时间，满足了产品快速迭 代的需求。

为实现上述目的，本申请实施例提供如下技术方案：

本申请实施例提供了一种编译处理方法，所述方法包括：

获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预 编译指令；

利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所 述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多 个源代码文件之间存在的间接依赖关系；

筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖 关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删 除；

采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源 代码文件。

本申请实施例还提供了一种编译处理装置，所述装置包括：

第一获得模块，用于获得目标项目的多个源代码文件，并确定所述多个 源代码文件包含的预编译指令；

第二获得模块，用于利用确定的预编译指令，获得所述多个源代码文件 存在的依赖关系，所述依赖关系包括所述多个源代码文件各自存在的直接依 赖关系，以及所述多个源代码文件之间存在的间接依赖关系；

筛选模块，用于筛选使所述多个源代码文件中存在的依赖关系数量变动 最多的直接依赖关系；

处理模块，用于将筛选出的直接依赖关系对应的预编译指令从相应的源 代码文件删除；

修复模块，用于采用前置声明的方式，更新当前的多个源代码文件，得 到多个待编译源代码文件。

本申请实施例还提供了一种电子设备，所述电子设备包括：

通信接口；

存储器，用于存储实现如上所述的编译处理方法的程序；

处理器，用于加载并执行所述程序，包括：

获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预 编译指令；

利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所 述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多 个源代码文件之间存在的间接依赖关系；

筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖 关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删 除；

采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源 代码文件。

基于上述技术方案，本申请实施例提供了一种编译处理方法、装置及电 子设备，对于大型项目划分成的多个模块对应的多个源代码文件，通过获得 这多个源代码文件包含的预编译指令，从而据此获得这多个源代码文件存在 的直接依赖关系和间接依赖关系，之后，筛选出使这多个源代码文件中存在 的依赖关系数量变动最多的直接依赖关系，并将筛选出的直接依赖关系对应 的预编译指令从相应的源代码文件删除，再采用前置声明的方式，更新当前 的多个源代码文件，得到多个待编译源代码文件。可见，本申请通过减少多个源代码文件存在的依赖关系，从根源上达到了提高项目整体编译速度的效 果，同时减少了开发中重编译情况出现的几率，减少了开发人员的工作量， 缩短了整个项目的构建时间，满足了产品快速迭代的需求。

附图说明

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

图1为本申请实例提供的一种项目依赖关系图；

图2为本申请实施例提供的一种电子设备的硬件结构图；

图3为本申请实施例提供的一种编译处理方法的流程图；

图4为本申请实施例提供的另一种编译处理方法的流程图；

图5(a)为本申请实施例提供的一种关系网络图；

图5(b)为本申请实施例提供的另一种关系网络图；

图5(c)为本申请实施例提供的一种优化后的关系网络图；

图5(d)为本申请实施例提供的另一种优化后的关系网络图；

图6为本申请实施例提供的又一种编译处理方法的部分流程图；

图7为本申请实施例提供的一种编译处理装置的结构图；

图8为本申请实施例提供的另一种编译处理装置的结构图；

图9为本申请实施例提供的又一种编译处理装置的结构图；

图10为本申请实施例提供的又一种编译处理装置的结构图；

图11为本申请实施例提供的又一种编译处理装置的结构图。

具体实施方式

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

基于上述背景技术部分的记载，现有大型项目为了提高开发效率，通常 会进行模块划分，从而使多个开发人员分工合作，完成一个大型项目的开发。 由于划分得到的各模块都是该大型项目的一个组成部分，需要模块之间的相 互配合，才能保证大型项目的正常工作。所以说，大型项目划分出的多个模 块之间往往具有一定依赖关系。

在软件工程对象模型中，依赖关系通常描述两个模型元素(类、用例等) 之间的语义连接关系，其中一个模型元素是独立的，另一个模型元素不是独 立的，它就依赖于独立的模型元素，如果独立的模型元素改变了，将影响依 赖于它的模型元素。

例如：一个类使用另一个类的对象作为操作的参数，一个类用另一个类 的对象作为它的数据成员，一个类向另一个类发消息等，这样的两个类之间 都存在依赖关系。在类图中，可以采用带箭头的线连接有依赖关系的两个类， 箭头指向独立的类，还可以在该线上添加版类标签，具体说明依赖的种类等 等。

由此可见，在本申请中，上述依赖关系可以指大型项目中模块A直接或间 接引用或包含了模块B，可以称该项目存在一个模块A依赖于模块B的关系。

在实际应用中，为了提高大型项目编译效率，目前通常采用以下几个方 式实现源程序的编译处理：

方式一：分布式编译方案，即将编译的整个工作量通过分布计算的方法 分配到多个计算机上执行，也就是说将大型项目的各模块分发到不同网络节 点进行编译，达到并行编译的效果，从而缩短大型项目编译时间，具体可以 采用Incredibuild这一C++分布式编译软件实现。

方式二：由于大部分C++大型项目通常都会使用PCH(pre-Compile Header，预编译头文件)，基于此，现有技术通常还会采用预先将常用的公共 头文件预编译成中间格式(如目标文件)的方式，来节约反复编译这些头文 件的时间，提高大型项目开发效率。

方式三：利用CCache这一C++编译工具，通过将头文件高速缓存到源文 件中而改进构建性能，从而通过减少每一步编译时添加头文件所需要的时间， 达到提高大型项目构建速度的目的。可见，这种方式在编译特定部分时，使 用缓存信息而不必重新读取解析文件，节约了编译时间。

方式四：某些场景中，还可以采用打包编译处理方法(UnityBuild)，将 若干编译单元打包到同一个编译单元，从而减少重复编译头文件，提高编译 速度。

然而，上述列举的几种编译处理方法，对于C++大型项目，其优化的只是 项目整体的构建速度，并未改善各模块之间的错综复杂的依赖关系，如过度 耦合关系，以Incredibuild方案为例，若模块之间的耦合度过高，将会导致方案 预处理的时间很长，并且，在任一个编译节点上进行编译工作时，所需要的 依赖模块文件会很多，从而造成网络传输数据量增加，往往会抵消Incredibuild 方案自身的优势，甚至会使得项目编译速度更低。

举例说明，参照图1所示的项目中模块之间的依赖关系示意图，假设模块 B中出现了模块A的包含指令(即include指令)，可以称存在从模块B到模块A 的一个依赖关系，即模块B依赖于模块A，基于此，在该图1中，实线表示的是 通过include指令直接看到的依赖关系，即直接依赖关系，虚线则表示该项目 中隐含的模块之间的依赖关系，即间接依赖关系，如图1所示，由于B.h对A.h 存在一个依赖关系，从而使得B.h的所有下游模块都对A.h产生了依赖，即B.Cpp对A.h隐含存在一个依赖关系，所以说，A.h与B.h之间存在直接依赖关 系，A.h与B.Cpp存在间接依赖关系。

申请人经研究发现，在大型项目的开发中，上述描述的隐含的依赖关系 即间接依赖关系往往会拖慢编译速度，比如，在开发过程中图省事在头文件A (如A.h)中，不恰当的包含了另一个头文件B(如B.h)，导致今后无论是B 或者B的下游模块(如B.Cpp等)有所改动时，都会导致A和A的下游模块(如 A.Cpp)重新编译，工作量非常大。

或者，在某个阶段，模块A需要模块B提供的功能，因此，模块A将模块B 包含进来，即建立了两者之间的依赖关系，但后续处理阶段实现的改动使得 模块B的引入不再必要，然而，上述列举的几种编译处理方法的编译环境中， 并没有提供一个剔除不需要模块的功能，也就产生了一个完全不必要的编译 负担，影响编译速度。

由此可见，在大型项目中，模块之间的不恰当的依赖关系是影响项目编 译速度的核心问题，为了改善该问题，真正地提高项目编译速度，本申请提 出将模块之间的冗余依赖关系剔除，从而解决了因模块之间过度依赖关系， 而降低项目整体编译速度的技术问题。

需要说明的是，本申请实施例提供的编译处理方法可以应用于具有数据 处理能力的电子设备，该电子设备可能是网络侧设置的服务器，也可能是用 户侧设置的PC(个人计算机)等终端设备；该电子设备可以通过装载实现本 申请实施例提供的编译处理方法相应的程序的系统，其中，该程序可以存储 于计算设备的存储器中，并由处理器调用实现程序功能；

可选的，图2示出了本申请实施例提供的电子设备的硬件结构框图，参 照图2，该电子设备可以包括：通信接口21、存储器22以及处理器23。

在本申请实施例中，通信接口21、存储器22、处理器23的数量可以为 至少一个，且通信接口21、存储器22、处理器23可以通过通信总线完成相 互间的通信；

可选的，通信接口22可以为通信模块的接口，如GSM模块的接口；

存储器22可能包含高速RAM存储器，也可能还包括非易失性存储器 (non-volatile memory)，例如至少一个磁盘存储器。在本申请中，该存储器22可以存储实现本申请实施例提供的编译处理方法的程序，以及大型项目的 源代码文件，以及程序执行过程中生成的中间数据等等。

处理器23可能是一个中央处理器CPU，或者是特定集成电路ASIC (ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例 的一个或多个集成电路。

在本申请实施例中，处理器23可以调用存储器22所存储的程序可以实现 本申请实施例提供的编译处理方法。

需要说明的是，图2所示电子设备的硬件结构仅是可选的，根据使用需要， 电子设备还可以设置显示屏、信息输入装置(键盘、鼠标等)等。在实际应 用中，当需要对某大型项目的源程序进行处理，以得到对应的可执行文件时， 可以启动电子设备中的相应应用程序，载入该大型项目的多个源代码文件， 调取存储器存储的程序并执行，从而得到所需的可执行文件。可选的，在整 个处理过程中，可以通过显示屏显示程序处理进度以及编译结果。

基于上述描述，参照图3，为本申请实施例提供的一种编译处理方法的流 程图，该方法可应用于电子设备，具体可以包括以下步骤：

步骤S301，获得目标项目包含的多个源代码文件，并确定该多个源代码 文件包含的预编译指令；

在本领域，源代码文件中通常会包括各种预编译指令，这些指令可以称 为预处理命令或预处理器，主要作用是通过预处理的内建功能，对一个资源 进行等价替换。

其中，预编译也称预处理可以包括文件包含、宏替换、条件编译和布局 控制等。相应地，预编译指令可以包括文件包含指令即include指令，宏替换 指令即define指令，条件编译指令如if指令，ifndef指令，ifdef指令，endif指令 以及undef指令等，布局控制指令即pragma指令等。

基于此，在实际应用中，获得源代码文件后，可以通过预处理器对该源 代码文件进行预处理(或者说是预编译)，如将所有的#define删除，并展开 所有的宏定义，处理所有的条件预编译指令，处理#include预编译指令，将被 包含的文件插入到该预编译指令的位置，删除所有注释“//”“/”，添加行号 和文件标识，以便编译时产生调试用的行号及编译错误警告行号，保留所有 的#pragme编译器指令等等。本申请对源代码文件的预处理方法不做详述。

其中，#include主要是为文件的引用组合源程序正文，#define可以定义符 号常量、函数功能、重新命名、字符串的拼接等各种功能，而#if，#ifndef， #ifdef，#endif，#undef等条件编译指令，主要是进行编译时有选择的挑选，注 释掉一些指定的代码，以达到版本控制、防止对文件重复包含的功能。#pragme 主要功能是设定编译器的状态，或者是指示编译器完成一些特定的动作或为 编译程序提供非常规的控制流信息。

步骤S302，利用确定的预编译指令，获得这多个源代码文件存在的依赖 关系；

其中，该依赖关系可以包括多个源代码文件各自存在的直接依赖关系， 以及多个源代码文件之间存在的间接依赖关系。结合上图1，对于包含A.h以 及A.cpp等文件的源代码文件A，以及包含B.h以及B.cpp等文件的源代码文件 B，源代码文件A引用了源代码文件B，具体为A.h包含B.h(即A.h与B.h具有直 接依赖关系)，从而由此增加了A.h与B.cpp之间的间接依赖关系。

而对于每个源代码文件包含的各种文件之间的依赖关系，可以根据代源 码文件的内容确定，仍如1所示，除了上述说明的依赖关系外，A.h与A.cpp存 在直接依赖关系，B.h与B.cpp存在直接依赖关系。

由此可见，对于大型项目来说，由于其每个模块的源代码文件包含的文 件往往很多，各源代码文件之间的引用或包含关系也会比较复杂，进而会源 代码文件之间的某一直接依赖关系，而带来大量间接依赖关系，从而使各源 代码文件之间的依赖关系错综复杂。

步骤S303，选择这多个源代码文件中存在的直接依赖关系作为候选依赖 关系；

结合上述分析，由于多个源代码文件中存在的直接依赖关系，决定了多 个源代码文件之间存在的间接依赖关系，所以，本申请实施例为了筛选出使 得多个源代码文件中存在的依赖关系数量变动最多的直接依赖关系，以便将 其从相应的源代码文件删除，从而达到提高对多个源代码文件的编译速度的 目的，可以依次选择一个直接依赖关系作为候选依赖关系，之后，统计删除 该候选依赖关系后，对这多个源代码文件存在的依赖关系数量的影响。

基于此，本申请实施例可以选择这多个源代码文件中存在的任意一个直 接依赖关系作为候选依赖关系，等下一次选择时，重新选择一个新的直接依 赖关系作为候选依赖关系，依次类推，直至完成对所有直接依赖关系的筛选。

可选的，本申请还可以统计这多个源代码文件中存在的直接依赖关系的 数量，从而按照所得数量进行迭代筛选，直至迭代次数达到该直接依赖关系 的总数量。

步骤S304，统计删除每个候选依赖关系后这多个源代码文件当前存在的 依赖关系数量；

在本实施例实际应用中，在删除当前的候选依赖关系后，这多个源代码 文件中的依赖关系，将会随着该候选依赖关系的删除有所变动，如因该候选 依赖关系产生的间接依赖关系，仍如图1所示的依赖关系图，若A.h与B.h 之间的直接依赖关系删除后，A.h与B.cpp之间的间接依赖关系将会消失，从 而使整个依赖关系图中的依赖关系总数量减少。

因此，在删除当前的候选依赖关系后，本申请实施例可以更新这多个源 代码文件当前存在的依赖关系，再统计当前存在的依赖关系数量，需要说明 的是，统计的依赖关系数量包括当前存在的直接依赖关系数量与间接依赖关 系数量的总和。

可选的，在本申请实施例中，每次统计完多个源代码文件当前存在的依 赖关系数量，可以判断当前统计次数是否达到初始多个源代码文件存在的直 接依赖关系的总数量，即是否达到选择出的候选依赖关系的数量，如果否， 可以重新选择一个候选依赖关系继续统计，如果是，执行步骤S305。

另外，本申请可以将每次统计得到的多个源代码文件当前存在的依赖关 系数量，与本次所选候选依赖关系对应存储，具体可以采用对应关系表方式 进行存储，但并不局限于此。

步骤S305，确定最少依赖关系数量对应的候选依赖关系为目标依赖关系；

可选的，本申请可以将统计得到的对应不同候选依赖关系的统计数量进 行排序，从而确定最小统计结果即统计得到的多个源代码文件当前存在的最 少依赖关系数量，并将其对应的候选依赖关系作为目标依赖关系。可见，将 该目标依赖关系删除后，将会导致多个源代码文件存在的依赖关系数量减少 最多。

步骤S306，将该目标依赖关系对应的预编译指令从相应的源代码文件删 除；

在实际应用中，由于直接将确定出的目标边对应的模块之间的依赖关系， 即某个源程序文件中的预编译指令从该源程序文件删除后，通常会造成后续 无法正常执行编译步骤，需要在现有的编译步骤基础上进行修复。

步骤S307，采用前置声明的方式，更新当前的多个源代码文件，得到多 个待编译源代码文件；

在C++/C程序文件(如.c文件)中通常由头文件((header files，如.h文件) 和定义文件(definition files)组成，头文件作为一种包含功能函数、数据接口 声明的载体文件，主要用于保存程序的声明，而定义文件用于保存程序的实 现。头文件作为源代码文件和函数库之间的桥梁和纽带，在编译时，编译器 通过头文件找到对应的函数库，进而把已引用函数的实际内容导出来代替原 有函数，进而在硬件层面实现功能。

其中，头文件一般由开头处的版权和版本声明，预处理块，inline函数的 定义，函数和类结构声明等，通常情况下，可以用ifndef/define/endif结构产 生预处理块(即预编译块)，用#include格式来引用库的头文件。

基于此，当出现头文件对类型的时候，可以在源代码文件开始加上该类 型的前置声明，这样就不必包含该头文件；而对于需要枚举定义的，可以使 用C++11的新枚举类型添加前置声明，其中，C++11即为C++0x，是C++编程 语言的一个较新的标准，为C++引入了类型推导、Lambda函数、外部模板等 现代特性。此外，还可以在头文件中写模板声明，将相应的定义写在唯一的 实现文件中，之后，使用PIMPL(pointer to implementation,指向实现的指针) 模式分离接口和实现，从而降低编译依赖、提高重编译速度。

所以，上述步骤S307具体可以包括以下方法实现对当前多个源代码文件 的更新，即对删除了目标依赖关系后的多个源代码文件的修复。

检测到当前的多个源代码文件中存在定义类型的头文件，在相应源代码 文件的初始位置增加定义所述类型的前置声明；删除所述头文件中对所述类 型的定义，并在所述头文件中进行模板声明，将所述类型的定义写入相应源 代码文件中的实现文件中；通过指向实现的指针PIMPL模式，实现接口与实 现的分离。

步骤S308，对更新后多个待编译源代码文件进行编译，得到相应的目标 文件；

在本申请实施例中，完成对源代码文件的预编译过程即预处理过程后， 编译器对得到的更新后的多个源代码文件进行编译得到目标文件，具体可以 包括词法分析、语法分析、语义检查和中间代码生成、代码优化这部分，才 能将源代码文件翻译成目标文件。其中，词法分析和语法分析可以称为源程 序分析，分析过程中，发现有语法错误，可以通过显示屏输出提示信息。需 要说明的是，本申请实施例对上述编译的具体实现方法不做详述。

其中，得到的目标文件通常是由汇编代码转化成的二进制文件，以便机 器能够读取该目标文件，即.obj文件。

步骤S309，利用得到的多个目标文件以及获取的库文件进行链接处理， 得到目标项目的多个源代码文件对应的可执行文件。

其中，链接其实就是将二进制文件链接称为一个可执行的指令，链接所 完成的任务是合并段表，然后把符号表合并，并对符号表进行重定位。可见， 该链接处理实际上是将各个目标文件中的各段代码进行绝对地址定位，生成 跟特定平台相关的可执行文件。

本申请实施例可以将.obj文件生成.exe文件(即可执行文件)的过程称为 链接，本申请对链接器对得到的.obj目标文件以及需要的.Lib库文件进行链接 处理的具体方法不做详述。而且，通常情况下，生成可执行文件后，对应的 目标文件可以删除，以节约内存资源。

综上所述，在本申请实施例中，对于大型项目划分成的多个模块对应的 多个源代码文件，通过获得这多个源代码文件包含的预编译指令，从而据此 获得这多个源代码文件存在的直接依赖关系和间接依赖关系，之后，筛选出 使这多个源代码文件中存在的依赖关系数量变动最多最多的直接依赖关系， 并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删除，再 采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码 文件。可见，本申请通过减少多个源代码文件存在的依赖关系，从根源上达到了提高项目整体编译速度的效果，同时减少了开发中重编译情况出现的几 率。

作为本申请另一实施例，对于使所述多个源代码文件中存在的依赖关系 数量变动最多的直接依赖关系的筛选，本申请可以利用图遍历算法实现，具 体的，参照图4所示的另一种编译处理方法的流程图，该方法可以包括：

步骤S401，获得目标项目包含的多个源代码文件，并确定该多个源代码 文件包含的预编译指令；

步骤S402，利用确定的预编译指令，获得这多个源代码文件存在的依赖 关系；

其中，该依赖关系可以包括多个源代码文件各自存在的直接依赖关系， 以及多个源代码文件之间存在的间接依赖关系。

步骤S403，利用多个源代码文件之间存在的直接依赖关系和间接依赖关 系，构建关系网络图；

参照上图1所示的关系网络图，本申请实施例可以将每一个源代码文件及 其包含的各文件作为节点，利用得到的各源代码文件存在的依赖关系，以及 各源代码文件之间存在的依赖关系，构成相应节点之间的有向边。可见，本 实施例得到的关系网络图实际上是有向图。

步骤S404，获得该关系网络图中直接依赖关系对应边的第一总边数；

可选的，本申请为了方便描述图遍历算法实现对目标依赖关系的筛选过 程，可以利用由多个源代码文件存在的所有直接依赖关系，构成关系网络子 图。

可见，本申请实施例中，关系网络图可以包含关系网络子图中所有的节 点和边，关系网络图除了包括关系网络子图中的所有边外，还包括根据关系 网络子图中节点间的直接依赖关系，得到的节点之间隐含依赖关系的边。

比如，参照图5(a)和图5(b)所示的网络图，若多个源代码文件包括 A.h、A.cpp、B.h、B.cpp、C.h、C.cpp等文件，A.cpp是A.h下游节点，B.cpp 是B.h下游节点，C.cpp是C.h下游节点，而A.h和C.h均引用了B.h，也就是说， A.h包含B.h，C.h包含B.h，从而使A.h和C.h间接包含了B.cpp，即A.h与B.cpp 存在间接依赖关系，C.h与B.cpp存在间接依赖关系。基于此，本实施例可以构 建如图5(a)所示的关系网络图，以及如图5(b)所示的关系网络子图，显 然，构建的关系网络图与关系网络子图对比，多了虚线箭头表示的A.h与B.cpp 存在的间接依赖关系，C.h与B.cpp存在的间接依赖关系。

基于此，本申请实施例获得关系网络图中直接依赖关系对应边的第一总 边数，实际上就是获得关系网络子图包含的总边数。

步骤S405，删除关系网络图中直接依赖关系对应的第一边，更新关系网 络图，并统计更新后的关系网络图中各依赖关系对应的边的第二总边数；

本实施例中，选择关系网络图中存在的任意一个直接依赖关系对应的边 为第一边，删除该第一边后，由于其会引起关系网络图中的间接依赖关系的 减少，所以，此时可以先更新该关系网络图，再统计更新后的关系网络图当 前存在的总边数作为第二总边数。

结合上图5(a)和图5(b)，该图中实线表示节点之间的直接依赖关系， 虚线表示节点之间的间接依赖关系。本实施例是从图5(b)中任意选择一条 边作为第一边，若将A.h和A.Cpp之间的边作为第一边，将其删除后，关系网 络图相应变为如图5(c)；若将A.h和B.h之间的边作为第一边，删除该第一边 后，关系网络图更新后将变为图5(d)。可见，删除不同的第一边，更新后 的关系网网络图减少的边的数量是不同的，则统计得到的关系网络图中的总 边数是不同的。

步骤S406，判断关系网络图的当前更新次数是否达到第一总边数，若是， 进入步骤S407，若否，选择新的第一边，并返回步骤S405；

在本申请实施例中，需要统计网络关系子图中的每一条删除后，更新后 的关系网络图包含的第二总边数，才能得到使得关系网络图包含的总边数变 动最多的第一边，因此，每完成一次统计，可以判断对关系网络图的当前更 新次数是否达到第一总边数，也可以判断当前统计次数是否达到第一总边数， 本申请对此不做限定。

其中，在确定没有完成第一总边数相同次数的更新后，可以选择关系网 络图中的其他直接依赖关系对应的边作为第一边，返回上述步骤S405继续统 计新的第一边对应的第二总边数，直至完成第一总边数相同次数的更新或统 计。

需要说明的是，完成一次上述统计后，需要将关系网络图恢复到初始状 态，也就是说，本申请实施例每次更新关系网络图都是对构建的初始关系网 络图进行更新，假设一次更新关系网络图变为图5(c)所示的结构，那么下 次选择新的第一边，并在更新关系网络图时，不是对图5(c)所示的网络图 更新，而是对如图5(a)所示的网络图更新。

步骤S407，对统计得到的多个第二总边数进行比较，获得最小第二总边 数对应的第一边作为目标边；

本申请实施例可以通过上述方式确定能将关系网络图边数减少最多的 边，即为上述瓶颈边。

步骤S408，将该目标边对应的源代码文件中的预编译指令删除，并采用 前置声明的方式更新目标项目的多个待编译源代码文件；

步骤S409，对更新后多个待编译源代码文件进行编译，得到相应的目标 文件；

步骤S410，利用得到的多个目标文件以及获取的库文件进行链接处理， 得到目标项目的多个源代码文件对应的可执行文件。

其中，链接其实就是将二进制文件链接称为一个可执行的指令，链接所 完成的任务是合并段表，然后把符号表合并，并对符号表进行重定位。可见， 该链接处理实际上是将各个目标文件中的各段代码进行绝对地址定位，生成 跟特定平台相关的可执行文件。

本申请实施例可以将.obj文件生成.exe文件(即可执行文件)的过程称为 链接，本申请对链接器对得到的.obj目标文件以及需要的.Lib库文件进行链接 处理的具体方法不做详述。而且，通常情况下，生成可执行文件后，对应的 目标文件可以删除，以节约内存资源。

综上，在本申请实施例，通过将项目中的多个源代码文件及其存在的依 赖关系抽象为有向图，即关系网络图，从而使用图遍历算法进行分析，确定 出依赖关系的瓶颈，即对关系网络图中的边影响最多的目标边，将该目标边 删除，得到一个依赖关系较少的目标项目，之后，可以采用现有的常规编译 处理方案进行后续编译处理，不仅提高了整体编译速度，同时减少了开发中 的重编译情况出现的几率，减少了开发人员的工作量。

作为本申请又一实施例，对于上述实施例确定目标边的过程，具体可以 采用深度优化图(Depth-First-Search-Grafh)算法进行优化，所以，如图6所示 的又一种编译处理方法的流程图，该方法可以包括以下步骤：

步骤S601，利用多个源代码文件存在的依赖关系，构建关系网络图；

本实施例中，关于多个源代码文件存在的依赖关系以及关系网络图的构 建方法，可以参照上述实施例相应部分的描述，本实施例在此不再赘述。

步骤S602，以该关系网络图中的每个顶点为根节点，获得相应的DFS树；

其中，DFS树包括与选择的根节点存在依赖关系的多个子节点，具体结构 可以根据多个源代码文件的内容确定，本申请实施例对此不做限定。

步骤S603，确定关系网络图中各直接依赖关系对应的边所在的DFS树的数 量；

在本申请实施例，可以选择任意一个直接依赖关系对应的边为第一边， 若第一边在顶点u的DFS树上，删除该第一边，将会导致对u的DFS树的边 数减一，仍以上图1为例，选择B.h->B.cpp为第一边，其是在顶点A.h的DFS 树上，如果删去该边，则造成A.h的DFS树的大小减一。

基于此，本申请可以确定关系网络图中存在的每个直接依赖关系对应的 边，对于该边所在的每个DFS树，因删除该边，都会造成其所在DFS树的大 小减一，所以，本申请实施例可以统计每一个直接依赖关系对应的边所在的 DFS树的数量。

步骤S604，选择所在DFS树的数量最多的边为目标边。

结合上述分析，若删除关系网图中的目标边，将会导致该关系网络图的 边数较少的最多，为了减少目标项目中的依赖关系数量，本实施例可以删除 该目标边，之后，再对处理后的多个源代码文件进行编译处理，得到相应的 可执行文件，后续处理过程可以参照上述实施例的描述，本实施例在此不再 赘述。

综上，本申请可以通过上述方式确定出目标边，采用删除目标边的方式， 实现对目标项目中依赖关系的优化，从而解决了上述现有的各种编译处理方 式因错综复杂的依赖关系，而影响编译速度的技术问题。

在实际应用中，对于大型项目的任意一个C++模块的编译链接过程，大致 可以分为预编译(或者预处理)、编译、链接几个步骤，本申请实施例提供 的编译处理方法，主要是对预编译以及编译两个步骤的改进。

其中，预处理可以由预处理器将C++模块的源代码文件中的预编译指令进 行展开，具体可以是宏的展开以及包含指令的处理；编译步骤可以由编译器 将处理后的源代码文件编译成目标平台汇编，再由汇编器转换为二进制目标 文件；链接步骤可以由链接器将编译得到的目标文件以及需要的库文件链接 为可执行文件。

基于此，当用户需要对某C++大型项目的各模块的源代码文件编译成可执 行文件时，可以启动电子设备上的相应数据处理平台，进入项目编译界面， 用户可以点击“加载源程序”按钮，从而加载该大型项目的多个源代码文件， 待加载完毕后，可以点击“启动编译”按钮，从而调取存储的实现上述编译 处理方法的程序，对加载的多个源代码文件进行处理，得到各模块的可执行 文件。在此可见，可以通过显示屏显示编译处理过程。

之后，当用户需要使用该大型项目时，可以直接点击上述得到的可执行 文件对应的项目图标，系统将会自动运行该项目，满足实际需要。

如图7所示，为本申请实施例提供的一种编译处理装置的结构图，该装置 可以包括：

第一获得模块71，用于获得目标项目的多个源代码文件，并确定所述多 个源代码文件包含的预编译指令；

第二获得模块72，用于利用确定的预编译指令，获得所述多个源代码文 件存在的依赖关系，所述依赖关系包括所述多个源代码文件各自存在的直接 依赖关系，以及所述多个源代码文件之间存在的间接依赖关系；

筛选模块73，用于筛选使所述多个源代码文件中存在的依赖关系数量变 动最多的直接依赖关系；

处理模块74，用于将筛选出的直接依赖关系对应的预编译指令从相应的 源代码文件删除；

修复模块75，用于采用前置声明的方式，更新当前的多个源代码文件， 得到多个待编译源代码文件。

可选的，如图8所示，上述筛选模块73可以包括：

第一确定单元7311，用于确定所述多个源代码文件中存在的直接依赖关 系；

第一统计单元7312，用于统计删除每个确定的直接依赖关系后所述多个 源代码文件当前存在的依赖关系数量；

第一选择单元7313，用于选择最少依赖关系数量对应的直接依赖关系为 目标依赖关系。

作为本申请另一实施例，如图9所示，上述装置还可以包括：

构建模块76，用于利用所述多个源代码文件存在的直接依赖关系和间接， 构建关系网络图；

相应地，筛选模块具体可以用于基于所述关系网络图，利用图遍历算法， 确定使所述关系网络图的总边数变动最多的直接依赖关系对应的目标边。

在实际应用中，如图9所示，该筛选模块73可以包括：

第一获得单元7321，用于获得所述关系网络图中直接依赖关系对应边的 第一总边数；

第一处理单元7322，用于删除所述关系网络图中直接依赖关系对应的第 一边，更新所述关系网络图，并统计更新后的关系网络图中各依赖关系对应 的边的第二总边数；

第二选择单元7323，用于确定所述关系网络的当前更新次数未达到所述 第一总边数，选择所述关系网络图中其他直接依赖关系对应的边作为第一边， 触发所述第一处理单元；

比较单元7324，用于确定所述关系网络的当前更新次数达到所述第一总 边数，对统计的多个第二总边数进行比较；

第二获得单元7325，用于获得最小第二总边数对应的第一边作为目标边， 并确定所述目标边对应的直接依赖关系。

可选的，本申请可以采用DFS算法确定关系网络图中的目标边，基于此， 如图10所示，该筛选模块73可以包括：

第三获得单元7331，用于以所述关系网络图中每个顶点为根节点，获得 相应的深度优先搜索DFS树；

第二确定单元7332，用于确定所述关系网络图中各直接依赖关系对应的 边所在的DFS树的数量；

第三选择单元7333，用于选择所在DFS树的数量最多的边为目标边，并 确定所述目标边对应的直接依赖关系。

在上述各实施例的基础上，如图11所示，该装置还可以包括：

编译模块77，用于对得到多个待编译源代码文件进行编译，得到相应的 目标文件；

链接模块78，用于对得到的多个目标文件以及获取的库文件进行链接处 理，得到所述目标项目的多个源代码文件一一对应的可执行文件。

另外，上述修复模块75可以包括：

第一增加单元751，检测到当前的多个源代码文件中存在定义类型的头文 件，在相应源代码文件的初始位置增加定义所述类型的前置声明；

第二处理单元752，用于删除所述头文件中对所述类型的定义，并在所述 头文件中进行模板声明，将所述类型的定义写入相应源代码文件中的实现文 件中；

分离单元753，用于通过指向实现的指针PIMPL模式，实现接口与实现 的分离。

综上，本申请实施例利用大型项目划分成的多个模块对应的多个源代码 文件包含的预编译指令，获得这多个源代码文件存在的直接依赖关系和间接 依赖关系后，利用图遍历算法，实现对这些依赖关系的优化，即减少该大型 项目中的依赖关系数量，并采用前置声明的方式进行处理后的源代码文件的 修复。在该基础上，再采用现有的上述几种编译处理方式进行编译，即可解 决因错误复杂的依赖关系而无法真正有效提高编译速度的问题，同时减少了 开发中重编译情况出现的几率。

上面主要是从虚拟功能模块的角度描述装置的结构，下面将从实现上述 编译处理方法的实体设备，即电子设备的硬件组成来进行硬件结构的说明。

参照上图2所示的电子设备的硬件结构图，该电子设备可以包括：

通信接口21，其可以是WIFI模块、GSM模块或GPRS模块等无线通信 模块的接口，也可以是有线通信模块的接口，如USB口等，本申请对通信接 口的类型及其结构不作限定，

存储器22，用于存储实现上述的编译处理方法的程序。

在本申请实施例中，根据需要，该存储器22还可以存储种子包以及得到 的信息推送对象等信息。上述第一获得模块、第二获得模块、筛选模块、处 理模块以及修复模块等均可以作为程序模块存储在存储器中，由处理器执行 存储在存储器中的上述程序单元来实现相应的功能。

可选的，存储器可以包括计算机可读介质中的非永久性存储器，随机存 取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)等。

处理器23包含内核，由内核去存储器中调取相应的程序模块。内核可以 设置一个或以上，通过调整内核参数实现目标项目存在的大量依赖关系的优 化。具体的其可以用于加载并执行所述存储器存储的程序，包括：

获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预 编译指令；

利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所 述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多 个源代码文件之间存在的间接依赖关系；

筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖 关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删 除；

采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源 代码文件。

需要说明的是，关于处理器加载程序实现编译处理方法的过程，还可以 参照上述方法实施例相应部分的描述，本实施例在此不再赘述。

本申请实施例还提供了一种计算机存储介质，存储实现上述编译处理方 法的程序，该程序适用于处理器进行加载，以执行上述编译处理方法，关于 该编译处理方法的实现过程可以参照上述方法实施例相应部分的描述，本实 施例在此不再赘述。

本申请实施例还提供了一种计算机程序产品，当在电子设备执行时，能 够实现如上述编译处理方法步骤的程序，具体内容可以参照上述方法实施例 相应部分的描述，本实施例在此不再赘述。

需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非 排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅 包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种 过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语 句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品 或者设备中还存在另外的相同要素。本说明书中各个实施例采用递进的方式 描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之 间相同相似部分互相参见即可。对于实施例公开的装置和电子设备而言，由 于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法 部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示 例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现， 为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性 地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行， 取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定 的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本 申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、 处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存 储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可 编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的 任意其它形式的存储介质中。

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

Claims (15)

1.一种编译处理方法，其特征在于，所述方法包括：

获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预编译指令；

利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多个源代码文件之间存在的间接依赖关系；

筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删除；

采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码文件。

2.根据权利要求1所述的方法，其特征在于，所述筛选使所述多个源代码文件之间存在的依赖关系数量变动最多的直接依赖关系，包括：

确定所述多个源代码文件中存在的直接依赖关系；

统计删除每个确定的直接依赖关系后所述多个源代码文件当前存在的依赖关系数量；

选择最少依赖关系数量对应的直接依赖关系为目标依赖关系。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

利用所述多个源代码文件存在的直接依赖关系和间接，构建关系网络图；

相应地，所述筛选使所述多个源代码文件之间存在的依赖关系数量变动最多的直接依赖关系，包括：

基于所述关系网络图，利用图遍历算法，确定使所述关系网络图的总边数变动最多的直接依赖关系对应的目标边。

4.根据权利要求3所述的方法，其特征在于，所述基于所述关系网络图，利用图遍历算法，确定使所述关系网络图的总边数变动最多的直接依赖关系对应的目标边，包括：

获得所述关系网络图中直接依赖关系对应边的第一总边数；

删除所述关系网络图中直接依赖关系对应的第一边，更新所述关系网络图，并统计更新后的关系网络图中各依赖关系对应的边的第二总边数；

确定所述关系网络的当前更新次数未达到所述第一总边数，选择所述关系网络图中其他直接依赖关系对应的边作为第一边，返回所述删除所述关系网络图中直接依赖关系对应的第一边，更新所述关系网络图，并统计更新后的关系网络图中各依赖关系对应的边的第二总边数步骤；

确定所述关系网络的当前更新次数达到所述第一总边数，对统计的多个第二总边数进行比较；

获得最小第二总边数对应的第一边作为目标边，并确定所述目标边对应的直接依赖关系。

5.根据权利要求3所述的方法，其特征在于，所述基于所述关系网络图，利用图遍历算法，确定使所述关系网络图的总边数变动最多的直接依赖关系对应的目标边，包括：

以所述关系网络图中每个顶点为根节点，获得相应的深度优先搜索DFS树；

确定所述关系网络图中各直接依赖关系对应的边所在的DFS树的数量；

选择所在DFS树的数量最多的边为目标边，并确定所述目标边对应的直接依赖关系。

6.根据权利要求1所述的方法，其特征在于，所述采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码文件，包括：

检测到当前的多个源代码文件中存在定义类型的头文件，在相应源代码文件的初始位置增加定义所述类型的前置声明；

删除所述头文件中对所述类型的定义，并在所述头文件中进行模板声明，将所述类型的定义写入相应源代码文件中的实现文件中；

通过指向实现的指针PIMPL模式，实现接口与实现的分离。

7.根据权利要求1-6任意一项所述的方法，其特征在于，所述方法还包括：

对得到多个待编译源代码文件进行编译，得到相应的目标文件；

对得到的多个目标文件以及获取的库文件进行链接处理，得到所述目标项目的多个源代码文件一一对应的可执行文件。

8.一种编译处理装置，其特征在于，所述装置包括：

第一获得模块，用于获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预编译指令；

第二获得模块，用于利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多个源代码文件之间存在的间接依赖关系；

筛选模块，用于筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖关系；

处理模块，用于将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删除；

修复模块，用于采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码文件。

9.根据权利要求8所述的装置，其特征在于，所述筛选模块包括：

第一确定单元，用于确定所述多个源代码文件中存在的直接依赖关系；

第一统计单元，用于统计删除每个确定的直接依赖关系后所述多个源代码文件当前存在的依赖关系数量；

第一选择单元，用于选择最少依赖关系数量对应的直接依赖关系为目标依赖关系。

10.根据权利要求8所述的装置，其特征在于，所述装置还包括：

构建模块，用于利用所述多个源代码文件存在的直接依赖关系和间接，构建关系网络图；

相应地，所述筛选模块具体用于基于所述关系网络图，利用图遍历算法，确定使所述关系网络图的总边数变动最多的直接依赖关系对应的目标边。

11.根据权利要求10所述的装置，其特征在于，所述筛选模块包括：

第一获得单元，用于获得所述关系网络图中直接依赖关系对应边的第一总边数；

第一处理单元，用于删除所述关系网络图中直接依赖关系对应的第一边，更新所述关系网络图，并统计更新后的关系网络图中各依赖关系对应的边的第二总边数；

第二选择单元，用于确定所述关系网络的当前更新次数未达到所述第一总边数，选择所述关系网络图中其他直接依赖关系对应的边作为第一边，触发所述第一处理单元；

比较单元，用于确定所述关系网络的当前更新次数达到所述第一总边数，对统计的多个第二总边数进行比较；

第二获得单元，用于获得最小第二总边数对应的第一边作为目标边，并确定所述目标边对应的直接依赖关系。

12.根据权利要求10所述的装置，其特征在于，所述筛选模块包括：

第三获得单元，用于以所述关系网络图中每个顶点为根节点，获得相应的深度优先搜索DFS树；

第二确定单元，用于确定所述关系网络图中各直接依赖关系对应的边所在的DFS树的数量；

第三选择单元，用于选择所在DFS树的数量最多的边为目标边，并确定所述目标边对应的直接依赖关系。

13.根据权利要求8所述的装置，其特征在于，所述修复模块包括：

第一增加单元，检测到当前的多个源代码文件中存在定义类型的头文件，在相应源代码文件的初始位置增加定义所述类型的前置声明；

第二处理单元，用于删除所述头文件中对所述类型的定义，并在所述头文件中进行模板声明，将所述类型的定义写入相应源代码文件中的实现文件中；

分离单元，用于通过指向实现的指针PIMPL模式，实现接口与实现的分离。

14.根据权利要求8-13任意一项所述的装置，其特征在于，所述装置还包括：

编译模块，用于对得到多个待编译源代码文件进行编译，得到相应的目标文件；

链接模块，用于对得到的多个目标文件以及获取的库文件进行链接处理，得到所述目标项目的多个源代码文件一一对应的可执行文件。

15.一种电子设备，其特征在于，所述电子设备包括：

通信接口；

存储器，用于存储实现如权利要求1-7任意一项所述的编译处理方法的程序；

处理器，用于加载并执行所述程序，包括：

获得目标项目的多个源代码文件，并确定所述多个源代码文件包含的预编译指令；

利用确定的预编译指令，获得所述多个源代码文件存在的依赖关系，所述依赖关系包括所述多个源代码文件各自存在的直接依赖关系，以及所述多个源代码文件之间存在的间接依赖关系；

筛选使所述多个源代码文件中存在的依赖关系数量变动最多的直接依赖关系，并将筛选出的直接依赖关系对应的预编译指令从相应的源代码文件删除；

采用前置声明的方式，更新当前的多个源代码文件，得到多个待编译源代码文件。