CN114817061A - 虚拟构建脚本的依赖性错误检测方法 - Google Patents

Abstract

本公开提供一种虚拟构建脚本的依赖性错误检测方法，包括：获取待构建的源程序文件及待检测的构建脚本，源程序文件指待编译的代码文件，构建脚本指用于编译构建源程序文件所需的脚本文件；对源程序文件进行修剪，删除源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；基于待检测的构建脚本，通过虚拟构建方法构建修剪后的程序的统一依赖关系图；基于统一依赖关系图进行依赖性错误检测。本公开还提供了一种虚拟构建脚本的依赖性错误检测装置、电子设备以及可读存储介质。

Description

虚拟构建脚本的依赖性错误检测方法

技术领域

本公开涉及计算机技术领域，尤其涉及一种虚拟构建脚本的依赖性错误检测方法、装置、电子设备及可读存储介质。

背景技术

随着大规模程序的发展，构建系统如Make、Ninja和Bazel，在程序编译和部署中发挥着越来越重要的作用。开发人员在构建脚本中定义规则来指定目标的依赖性，最终指导从源代码到可执行软件的转换。然而编译构建脚本的开发是很容易出错的，其中最常见的错误是依赖性错误，主要包括依赖缺失和冗余依赖，出现这些错误会导致编译结果与预期不符的错误构建以及影响到构建过程中的增量编译和并行编译导致构建效率降低。

当项目发展到非常大的规模时，由开发人员来检测和修复构建脚本中的依赖性错误往往非常耗费人力和时间，并且难以实现。为了解决这个问题，现有的方法试图从三个角度来自动检测构建依赖性错误。第一种方法通过解析和评估构建脚本获得静态依赖关系，然后从关系中发现错误。由于静态依赖关系是不健全的，缺少从实际构建过程中获得的实际依赖关系，因此只能检测到一部分的依赖性错误，如循环依赖。第二种方法跟踪构建过程以获得动态依赖关系。与第一类相似，由于缺少静态依赖关系，和第一种方法一样这种分析不能发现依赖缺失和冗余依赖。第三种方法通过将静态依赖关系和动态依赖关系融合到统一依赖关系图中，即UDG中，通过使用不同的策略遍历关系图来有效地检测依赖性错误。具体来说，分析比较UDG中的两种依赖关系，发现其中的不一致性，并根据不一致性的类型进一步检测是依赖缺失或是冗余依赖错误。其中，上述第三种方法是目前构建依赖性错误检测中最先进的工具VeriBuild所使用的方法，它能够精确地检测出构建脚本中的依赖性错误，但在对大型项目进行检测时需要巨大的时间开销，这使得它在分析大型项目时的实用性不足。

发明内容

为了解决上述技术问题中的至少一个，本公开提供了一种虚拟构建脚本的依赖性错误检测方法、装置、电子设备及可读存储介质。

根据本公开的一个方面，提供一种虚拟构建脚本的依赖性错误检测方法，包括：

获取待构建的源程序文件及待检测的构建脚本，所述源程序文件指待编译的代码文件，所述构建脚本指用于编译构建源程序文件所需的脚本文件；

对所述源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

基于所述待检测的构建脚本，通过虚拟构建方法构建所述修剪后的程序的统一依赖关系图；

基于所述统一依赖关系图进行依赖性错误检测。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，所述删除不影响动态依赖关系文件的一部分，包括：

删除所述源程序文件中的主体程序及其他函数定义的部分。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，所述依赖关系通过统一依赖关系图进行表示，所述统一依赖关系图表示为UDG＝(V,E)，V和E分别表示节点和边的集合；

其中，所述节点包括：

目标节点，所述目标节点

表示基于所述构建脚本构建目标时生成的目标文件，所述目标节点包括在编译源程序文件过程中生成的中间目标文件或最终目标文件；

文件节点，所述文件节点

表示存放于磁盘中的一个文件，所述文件节点包括所述源程序文件、构建脚本及库文件中的至少一个，所述库文件包括编译所述源程序文件所需的静态库或动态库；

其中，所述边包括：

表示与边e_SE连接的两个节点之间的依赖关系；

表示与边e_SS连接的两个节点在构建目标之前是静态可用的关系；

表示与边e_DA连接的两个节点在构建目标时被访问的关系；

表示与边e_DS连接的两个节点是在构建目标时生成或修改的关系。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，对所述待检测的源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序，包括：

基于源程序文件保存构建脚本的内容，以确保源程序文件和修剪后的文件的边集E_SE相同；

保留源程序文件和头文件的部分的include语句和宏定义语句，以保证修剪前的源程序文件和修剪后的文件在统一依赖关系图中的边集E_DA相等；

构造人工函数，并将所述人工函数替代所述源程序文件中的主函数的函数体，并使得所述人工函数与所述源程序文件在统一依赖关系图中的边集E_DS不发生变化；

其中，E_SE表示在统一关系图中的构建脚本中具有依赖关系的边的集合，E_DS表示在统一关系图中的文件是在构建目标时生成或修改的边的集合，E_DA表示在统一关系图中的文件在构建目标时被访问的边的集合。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，所述虚拟构建过程，包括：

通过统一依赖关系图生成器生成所述修剪后的程序的第一统一依赖关系图，将所述第一统一依赖关系图作为所述修剪后的程序的统一依赖关系图。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，所述虚拟构建过程还包括通过校准，所述校准包括：

如果在通过统一依赖关系图生成器生成所述修剪后的程序的第一统一依赖关系图的过程中出现构建失败，通过所述源程序文件执行实际的构建，生成第二统一依赖关系图；

通过图并算子将所述第一统一依赖关系图和所述第二统一依赖关系图合并在一起，将合并在一起的统一依赖关系图作为所述修剪后的程序的统一依赖关系图。

根据本公开至少一个实施方式的虚拟构建脚本的依赖性错误检测方法，所述基于所述统一依赖关系图进行依赖性错误检测，包括：

通过VeriBuild基于所述统一依赖关系图进行依赖性错误检测。

根据本公开的又一个方面，提供一种虚拟构建脚本的依赖性错误检测装置，包括：

文件获取模块，获取待构建的源程序文件及待检测的构建脚本，所述源程序文件指待编译的代码文件，所述构建脚本指用于编译构建源程序文件所需的脚本文件；

程序修剪模块，对所述源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

虚拟构建模块，基于所述待检测的构建脚本，通过虚拟构建方法构建所述修剪后的程序的统一依赖关系图；

错误检测模块，基于所述统一依赖关系图进行依赖性错误检测。

根据本公开的又一个方面，提供一种电子设备，包括：

存储器，所述存储器存储执行指令；

处理器，所述处理器执行所述存储器存储的执行指令，使得所述处理器执行上述任一项所述的方法。

根据本公开的又一个方面，提供一种可读存储介质，所述可读存储介质中存储有执行指令，所述执行指令被处理器执行时用于实现上述任一项所述的方法。

附图说明

附图示出了本公开的示例性实施方式，并与其说明一起用于解释本公开的原理，其中包括了这些附图以提供对本公开的进一步理解，并且附图包括在本说明书中并构成本说明书的一部分。

图1是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测方法流程示意图。

图2是根据本公开的一个实施方式的统一依赖关系图示意图。

图3是根据本公开的一个实施方式的基于统一依赖关系图的程序修剪的方法流程示意图。

图4是根据本公开的一个实施方式的基于统一依赖关系图的程序修剪的算法实现过程示意图。

图5是根据本公开的一个实施方式的源程序和经过修剪程序修剪后的程序示例。

图6是根据本公开的一个实施方式的虚拟构建脚本的方法流程示意图。

图7是根据本公开的一个实施方式的校准策略示例图。

图8是根据本公开的一个实施方式的使用校准的虚拟构建算法实现过程示意图。

图9是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测装置结构示意图。

图10是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测装置的性能验证实验数据表。

附图标记说明

1000 依赖性错误检测装置

1002 文件获取模块

1004 程序修剪模块

1006 虚拟构建模块

1008 错误检测模块

1100 总线

1200 处理器

1300 存储器

1400 其他电路。

具体实施方式

下面结合附图和实施方式对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施方式仅用于解释相关内容，而非对本公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分。

需要说明的是，在不冲突的情况下，本公开中的实施方式及实施方式中的特征可以相互组合。下面将参考附图并结合实施方式来详细说明本公开的技术方案。

除非另有说明，否则示出的示例性实施方式/实施例将被理解为提供可以在实践中实施本公开的技术构思的一些方式的各种细节的示例性特征。因此，除非另有说明，否则在不脱离本公开的技术构思的情况下，各种实施方式/实施例的特征可以另外地组合、分离、互换和/或重新布置。

在附图中使用交叉影线和/或阴影通常用于使相邻部件之间的边界变得清晰。如此，除非说明，否则交叉影线或阴影的存在与否均不传达或表示对部件的具体材料、材料性质、尺寸、比例、示出的部件之间的共性和/或部件的任何其它特性、属性、性质等的任何偏好或者要求。此外，在附图中，为了清楚和/或描述性的目的，可以夸大部件的尺寸和相对尺寸。当可以不同地实施示例性实施例时，可以以不同于所描述的顺序来执行具体的工艺顺序。例如，可以基本同时执行或者以与所描述的顺序相反的顺序执行两个连续描述的工艺。此外，同样的附图标记表示同样的部件。

当一个部件被称作“在”另一部件“上”或“之上”、“连接到”或“结合到”另一部件时，该部件可以直接在所述另一部件上、直接连接到或直接结合到所述另一部件，或者可以存在中间部件。然而，当部件被称作“直接在”另一部件“上”、“直接连接到”或“直接结合到”另一部件时，不存在中间部件。为此，术语“连接”可以指物理连接、电气连接等，并且具有或不具有中间部件。

本文使用的术语是为了描述具体实施例的目的，而不意图是限制性的。如这里所使用的，除非上下文另外清楚地指出，否则单数形式“一个(种、者)”和“所述(该)”也意图包括复数形式。此外，当在本说明书中使用术语“包含”和/或“包括”以及它们的变型时，说明存在所陈述的特征、整体、步骤、操作、部件、组件和/或它们的组，但不排除存在或附加一个或更多个其它特征、整体、步骤、操作、部件、组件和/或它们的组。还要注意的是，如这里使用的，术语“基本上”、“大约”和其它类似的术语被用作近似术语而不用作程度术语，如此，它们被用来解释本领域普通技术人员将认识到的测量值、计算值和/或提供的值的固有偏差。

图1是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测方法流程示意图。

如图1所示，虚拟构建脚本的依赖性错误检测方法S100，包括：

S102、获取待构建的源程序文件及待检测的构建脚本，源程序文件指待编译的代码文件，构建脚本指用于编译构建源程序文件所需的脚本文件；

S104、对源程序文件进行修剪，删除源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

S106、基于待检测的构建脚本，通过虚拟构建方法构建修剪后的程序的统一依赖关系图；

S108、基于统一依赖关系图进行依赖性错误检测。

其中，上述S104中，删除不影响动态依赖关系文件的一部分，包括：删除源程序文件中的主体程序及其他函数定义的部分。

其中，上述S108中，基于统一依赖关系图进行依赖性错误检测，包括：通过VeriBuild基于统一依赖关系图进行依赖性错误检测。

图2是根据本公开的一个实施方式的统一依赖关系图示意图。

如图2所示，上述图1实施方式中的依赖关系通过统一依赖关系图进行表示，统一依赖关系图表示为UDG＝(V,E)，V和E分别表示节点和边的集合；

其中，节点包括：

目标节点，目标节点

表示基于构建脚本构建目标时生成的目标文件，目标节点包括在编译源程序文件过程中生成的中间目标文件或最终目标文件；

文件节点，文件节点

表示存放于磁盘中的一个文件，文件节点包括源程序文件、构建脚本及库文件中的至少一个，库文件包括编译源程序文件所需的静态库或动态库；

其中，边包括：

表示与边e_SE连接的两个节点之间的依赖关系；

表示与边e_SS连接的两个节点在构建目标之前是静态可用的关系；

表示与边e_DA连接的两个节点在构建目标时被访问的关系；

表示与边e_DS连接的两个节点是在构建目标时生成或修改的关系。

其中，边集E_SE和E_SS通过分析和评估构建脚本获取，即通过静态统一依赖关系获得，边集E_DA和E_DS通过跟踪完整构建获取的动态统一依赖关系图。

图3是根据本公开的一个实施方式的基于统一依赖关系图的程序修剪的方法流程示意图。

上述S104中，对待检测的源程序文件进行修剪，删除源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序，可以通过图3所示的方法实现，具体包括：

S1042、基于源程序文件P保存构建脚本的内容，以确保源程序文件P和修剪后的文件P'的边集E_SE是相同的；

S1044、保留源程序文件和头文件的部分的include语句和宏定义语句，以保证修剪前的源程序文件P和修剪后的文件P'在统一依赖关系图中的边集E_DA相等；

S1046、构造人工函数，并将人工函数替代源程序文件P中的主函数的函数体，并使得人工函数与源程序文件P在统一依赖关系图中的边集E_DS不发生变化；

其中，E_SE表示在统一关系图中的构建脚本中具有依赖关系的边的集合，E_DS表示在统一关系图中的文件是在构建目标时生成或修改的边的集合，E_DA表示在统一关系图中的文件在构建目标时被访问的边的集合。

图4是根据本公开的一个实施方式的基于统一依赖关系图的程序修剪的算法实现过程示意图。上述S104可以通过图4所示的算法实现。

如图4所示算法1给出了程序修剪的过程，它将程序P作为输入，并将修剪后的程序P'作为输出。程序P'是P的简化版本，它抽象了不影响程序依赖关系模型的程序结构。首先，基于源程序文件P保存构建脚本的内容(第3行到第4行)，这样P和P'的边集E_SE是相同的。其次，保留源程序文件和头文件中的include语句和宏定义(第8行到第9行)，这可以保证两个程序的边集E_DA相等。第三，通过去除原主函数的函数体(第11到12行)，构造人工主函数，使它仍能生成可执行文件，保证边集E_DS不发生变化。最后，仍然创建一个与程序P中的文件相对应的空文件，即使它不包含影响依赖关系模型的程序构造(第13行)。因此，在构建特定目标之前静态可用的文件总是与原始程序中的文件相同。最后，程序P'正是虚拟构建需要的经过修剪后的程序。算法1只依赖于语法分析。对于给定的语法，只要提供了需要保留或转换的程序构造类型的规范，修剪后的程序的构造是可以确定的。本实施方式中的程序修剪算法利用一个轻量级的语法分析来生成一个修剪过的程序。最后对实验结果的评估还将证明，即使程序规模很大，程序修剪也只会引入很少的开销。

图5是根据本公开的一个实施方式的源程序和经过修剪程序修剪后的程序示例。

如图5所示，程序time_tool.cc，根据语法可以精确地识别所有的include语句和宏定义，并在新程序中保留文件time_tool.cc的第1到2行。对于第3到270行的函数实现将被删除。在使用c/c++语言实现的项目中，如果源程序包含main函数意味着它在构建完成之后能够生成可执行文件如果不保留main函数可能会导致编译构建过程失败，所以为了使目标构建和输出文件成功，还需要在新程序的文件time_tool.cc中构造一个人工main函数，同时清空其函数体，以避免不必要的编译过程。

本实施方式中，可以通过antlr实现程序修剪。程序修剪不能影响程序源程序文件，只能将程序修剪结果另存为一个新程序。当需要进行程序修剪时，首先将源程序文件编码转成UTF-8编码，然后将源程序的文本内容作为antlr的输入，antlr对其进行词法分析和语法分析，然后运行图4中的算法从获得的词法单元中保留预编译指令、宏定义和main函数入口，删去函数主体部分，再将它们输出到重定向文件中构成修剪过后的新程序。

图6是根据本公开的一个实施方式的虚拟构建脚本的方法流程示意图。

在上述S106中，通过虚拟构建方法构建修剪后的程序的统一依赖关系图，可以通过图6所示的方法实现，虚拟构建过程具体包括：

S1062、通过统一依赖关系图生成器生成修剪后的程序的第一统一依赖关系图；

S1064、判断上述S1062通过统一依赖关系图生成器生成修剪程序的第一统一依赖关系图时是否存在失败的情况；如果存在失败的情况，则到S1066，否则，到S1070；

S1066、通过源程序文件执行实际的构建，生成第二统一依赖关系图；

S1068、通过图算子将第一统一依赖关系图和第二统一依赖关系图合并在一起，作为修剪后的程序的统一依赖关系图；

S1070、将第一统一依赖关系图作为修剪后的程序的统一依赖关系图。

上述步骤S1066和S1068，实际上是在第一统一依赖关系图生成时发生存在构建失败的情况下，通校准策略实现的对统一依赖关系图的生成方法。

本实施方式中，虚拟构建过程可以通过UDG生成器Dg来构建经过程序修剪的项目的UDG。VeriBuild的UDG生成器Dg使用Linux操作系统下基于系统调用ptrac,实现的对目标进程进行跟踪、诊断、和调试的工具strace来追踪构建工具make对项目的构建过程，并且捕获执行make程序的进程的关于文件操作系统调用，同时获取相关的系统调用信息来构建UDG中的边集E_DA和e_DS，也就是通过跟踪完整构建来获取动态依赖关系。需要获取的信息主要包括：被操作文件的文件名，用来得知有哪些文件被操作了；系统调用名称，用来得知文件被执行了什么操作，判断是输入文件、输出文件、创建文件还是删除文件其中涉及的系统调用有openat、close、read、write、getcwd、chdir、unlink、rename和execve；执行系统调用的时间，用来比较执行顺序；执行系统调用的进程号，用来得知是为了构建哪个目标执行的操作。

另外，本实施方式中，虚拟构建需要将构建工具make在执行构建过程中使用的源程序P替换成修剪后的程序P'，实现这点同样需要追踪进程的系统调用，并且在检测到执行构建的进程在准备打开源程序文件或者头文件时通过修改系统调用的参数来实现替换功能，strace提供了追踪进程并且输出相关系统调用信息的功能，但没有提供修改系统调用参数的功能，而strace基于的系统调用ptrace提供了对应参数来实现这个功能，因此本文模仿strace基于ptrace实现了一个新的进程追踪工具来完成虚拟构建的工作，它能够在保证提供UDG生成器Dg对strace的追踪进程并输出系统调用信息需求的同时完成程序P到修剪后的程序P'替换功能。

图7是根据本公开的一个实施方式的校准策略示例图。

图7中所示项目gmp-6.2.1的构建脚本第1行中的依赖规则。目标fac_table.h依赖于目标gen-fac，目标gen-fac的构建结果将生成可执行文件gen-fac，但是由于进行的是虚拟构建，此时被构建出来的gen-fac只是一个用来体现依赖关系的空壳文件，并没有本该有的功能，而目标fac_table.h的构建命令需要通过执行程序gen-fac来完成，这就会导致构建失败，所以此时我们必须要转换到实际构建来保证目标fac_table.h的构建成功，也就是回到构建脚本的第一行，用修剪前的程序完成对目标fac_table.h的构建，包括fac_table.h所依赖的目标gen-fac，最后再重新回到虚拟构建中继续构建后面的目标。

通过make工具进行校准时，如果在虚拟构建过程中遇到有目标是需要由构建过程中生成的可执行文件构建的，将会出现构建失败的情况，当检测到被追踪进程非正常结束时，由于make进程在执行过程中会指出将目标分配给哪些子进程来执行构建，因此，通过获取出错进程的pid以及make执行中输出的信息就可以确定虚拟构建失败的目标，然后用修剪前的程序对出错目标进行实际构建同时获取对应系统调用信息。最后图8所示的算法获得完整的UDG。

图8是根据本公开的一个实施方式的使用校准的虚拟构建算法实现过程示意图。

如图8所示，算法2示出了使用校准的虚拟构建的过程。通过调用程序算法1所示的过程，可以获得修剪后的程序P'(第1到2行)，然后用其顶部目标t*构建程序P'(4至6行)。构建过程可以通过UDG生成器Dg来完成的，它可以有效地输出经过修剪后的程序的UDG。对于每个在虚拟构建中失败的目标，利用原始的程序P来执行实际的构建，该构建也依赖于UDG生成器Dg来构建一个补充的UDG(第8行到第10行)。最后，通过图并算子(第11行)将所有UDG合并在一起，产生一个相当于Dg(P)的UDG(统一依赖关系图)。

本公开提供的虚拟构建脚本的依赖性错误检测方法，通过虚拟构建的加速统一依赖关系图UDG的构建过程，并且在现有VeriBuild的基础上，实现了一个更高效的依赖错误检测方法，可用于为编译构建工具的构建脚本检测依赖性错误。它通过程序修剪算法利用一个轻量级的语法分析来生成一个修剪过的程序，保持了依赖模型等价性的同时大幅减少了编译构建的开销。它还使用了带有校准策略的虚拟构建算法，通过融合原始程序和修剪后程序的构建过程来处理由构建中生成的可执行文件构建的目标，最终生成等价的统一依赖图UDG。实验结果表明，本公开提供的虚拟构建脚本的依赖性错误检测方法，在分析检测大型项目时非常高效。它能够在260秒内完成对项目LLVM的分析，而最先进的方法Veribuild需要1851秒。此外，VirtualBuild可以保证检测的可靠性，检测结果与现有工具的检测结果相同。VirtualBuild通过虚拟构建加速构建UDG的功能使它能够无缝地扩展现有的基于UDG的依赖错误检测器，这显示出了它在项目构建维护方面的巨大潜力。

图9是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测装置1000结构示意图。

如图9所示，虚拟构建脚本的依赖性错误检测装置1000，包括：

文件获取模块1002，获取待构建的源程序文件及待检测的构建脚本，源程序文件指待编译的代码文件，构建脚本指用于编译构建源程序文件所需的脚本文件；

程序修剪模块1004，对源程序文件进行修剪，删除源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

虚拟构建模块1006，基于待检测的构建脚本，通过虚拟构建方法构建修剪后的程序的统一依赖关系图；

错误检测模块1008，基于统一依赖关系图进行依赖性错误检测。

需要说明的是，本实施方式中的上述各个模块的实现细节，与本公开提供的虚拟构建脚本的依赖性错误检测的方法的实现细节对应，此处不再一一赘述。

为了验证本实施方式中的虚拟构建脚本的依赖性错误检测装置1000的各项性能指标，选用VeriBuild的基准来评估VirtualBuild(依赖性错误检测装置1000)对构建UDG的效率的提高。基准测试包含了各种规模的知名开源项目，从数十行代码到数百万行代码。为了证明VirtualBuild在分析大型程序时的有效性和实用性，实验还选择了几个具有数百万行代码的额外项目，并与VeriBuild进行了进一步的比较。实验环境：每组实验在一台运行Linux系统的计算机上进行，该计算机使用Intel(R)Xeon(R)CPU E5-2698 v4@2.20GHz 40核处理器。包括以下验证实验。

(一)效率验证实验

为了量化VirtualBuild的效率提高，本公开测量了在UDG构建和整体分析中VirtualBuild的时间消耗。此外还比较了VirtualBuild和VeriBuild的开销，以显示效率的提高。由于实验环境的不同，本公开在受试者的基础上重新评估VeriBuild，并收集时间成本。实验结果如表1所示。总的来说，VirtualBuild在230秒内完成任何项目的UDG构建，在260秒内完成整体分析。平均而言，UDG构建和整体分析的速度分别加快了5.66倍和5.56倍。特别是，对于本验证实验中选用的项目http-parser,VirtualBuild构建UDG和完成依赖错误检测仅需0.23秒，而使用VeriBuild对项目进行分析需要13.36秒。效率的显著提高证明了虚拟构建的有效性以及VirtualBuild在构建脚本依赖性错误检测方面的实用性。

(二)消融实验

为了调查VirtualBuild中每个阶段的开销，本公开进行了一组消融研究，以量化VirtualBuild的三个阶段，即程序修剪、虚拟构建和构建UDG的时间开销。实验结果如表1所示，平均而言，它们在每次分析中分别花费0.8、5.45和7.02秒。

(三)可靠性和完整性

为了演示虚拟构建的可靠性和完整性，本公开量化了VirtualBuild和VeriBuild在构建脚本依赖错误报告方面的差异。图10是根据本公开的一个实施方式的虚拟构建脚本的依赖性错误检测装置的性能验证实验数据表。实验结果如图10中表1所示，VirtualBuild保持了VeriBuild的可靠性和完整性，在实验项目中报告了几乎相同的构建依赖错误报告。

根据本公开的又一个方面，提供一种电子设备，包括：

存储器，存储器存储执行指令；

处理器，处理器执行存储器存储的执行指令，使得处理器执行如上述任一项的方法。

根据本公开的又一个方面，提供一种可读存储介质，可读存储介质中存储有执行指令，执行指令被处理器执行时用于实现上述任一项的方法。

图9示出了采用处理系统的硬件实现方式的装置示例图。该装置可以包括执行上述流程图中各个或几个步骤的相应模块。因此，可以由相应模块执行上述流程图中的每个步骤或几个步骤，并且该装置可以包括这些模块中的一个或多个模块。模块可以是专门被配置为执行相应步骤的一个或多个硬件模块、或者由被配置为执行相应步骤的处理器来实现、或者存储在计算机可读介质内用于由处理器来实现、或者通过某种组合来实现。

该硬件结构可以利用总线架构来实现。总线架构可以包括任何数量的互连总线和桥接器，这取决于硬件的特定应用和总体设计约束。总线1100将包括一个或多个处理器1200、存储器1300和/或硬件模块的各种电路连接到一起。总线1100还可以将诸如外围设备、电压调节器、功率管理电路、外部天线等的各种其他电路1400连接。

总线1100可以是工业标准体系结构(ISA，Industry Standard Architecture)总线、外部设备互连(PCI，Peripheral Component)总线或扩展工业标准体系结构(EISA，Extended Industry Standard Component)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，该图中仅用一条连接线表示，但并不表示仅有一根总线或一种类型的总线。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本公开的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本公开的实施方式所属技术领域的技术人员所理解。处理器执行上文所描述的各个方法和处理。例如，本公开中的方法实施方式可以被实现为软件程序，其被有形地包含于机器可读介质，例如存储器。在一些实施方式中，软件程序的部分或者全部可以经由存储器和/或通信接口而被载入和/或安装。当软件程序加载到存储器并由处理器执行时，可以执行上文描述的方法中的一个或多个步骤。备选地，在其他实施方式中，处理器可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行上述方法之一。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，可以具体实现在任何可读存储介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

就本说明书而言，“可读存储介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。可读存储介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式只读存储器(CDROM)。另外，可读存储介质甚至可以是可在其上打印程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得程序，然后将其存储在存储器中。

应当理解，本公开的各部分可以用硬件、软件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施方式方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，的程序可以存储于一种可读存储介质中，该程序在执行时，包括方法实施方式的步骤之一或其组合。

此外，在本公开各个实施方式中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个可读存储介质中。存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施方式/方式”、“一些实施方式/方式”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施方式/方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施方式/方式或示例中。在本说明书中，对上述术语的示意性表述不必须的是相同的实施方式/方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施方式/方式或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施方式/方式或示例以及不同实施方式/方式或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

本领域的技术人员应当理解，上述实施方式仅仅是为了清楚地说明本公开，而并非是对本公开的范围进行限定。对于所属领域的技术人员而言，在上述公开的基础上还可以做出其它变化或变型，并且这些变化或变型仍处于本公开的范围内。

Claims (10)

1.一种虚拟构建脚本的依赖性错误检测方法，其特征在于，包括：

获取待构建的源程序文件及待检测的构建脚本，所述源程序文件指待编译的代码文件，所述构建脚本指用于编译构建源程序文件所需的脚本文件；

对所述源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

基于所述待检测的构建脚本，通过虚拟构建方法构建所述修剪后的程序的统一依赖关系图；以及

基于所述统一依赖关系图进行依赖性错误检测。

2.根据权利要求1所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，所述删除不影响动态依赖关系文件的一部分，包括：

删除所述源程序文件中的主体程序以及其他函数定义的部分。

3.根据权利要求1所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，所述依赖关系通过统一依赖关系图进行表示，所述统一依赖关系图表示为UDG＝(V,E)，V和E分别表示节点和边的集合；

其中，所述节点包括：

目标节点，所述目标节点

表示基于所述构建脚本构建目标时生成的目标文件，所述目标节点包括在编译源程序文件过程中生成的中间目标文件或最终目标文件；

文件节点，所述文件节点

表示存放于磁盘中的一个文件，所述文件节点包括所述源程序文件、构建脚本以及库文件中的至少一个，所述库文件包括编译所述源程序文件所需的静态库或动态库；

其中，所述边包括：

表示与边e_SE连接的两个节点之间的依赖关系；

表示与边e_SS连接的两个节点在构建目标之前是静态可用的关系；

表示与边e_DA连接的两个节点在构建目标时被访问的关系；

表示与边e_DS连接的两个节点是在构建目标时生成或修改的关系。

4.根据权利要求1所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，对所述待检测的源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序，包括：

基于源程序文件保存构建脚本的内容，以确保源程序文件和修剪后的文件的边集E_SE相同；

保留源程序文件和头文件的部分的include语句和宏定义语句，以保证修剪前的源程序文件和修剪后的文件在统一依赖关系图中的边集E_DA相等；以及

构造人工函数，并将所述人工函数替代所述源程序文件中的主函数的函数体，并使得所述人工函数与所述源程序文件在统一依赖关系图中的边集E_DS不发生变化；

其中，E_SE表示在统一关系图中的构建脚本中具有依赖关系的边的集合，E_DS表示在统一关系图中的文件是在构建目标时生成或修改的边的集合，E_DA表示在统一关系图中的文件在构建目标时被访问的边的集合。

5.根据权利要求1所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，所述虚拟构建过程，包括：

通过统一依赖关系图生成器生成所述修剪后的程序的第一统一依赖关系图，将所述第一统一依赖关系图作为所述修剪后的程序的统一依赖关系图。

6.根据权利要求5所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，所述虚拟构建过程还包括通过校准，所述校准包括：

如果在通过统一依赖关系图生成器生成所述修剪后的程序的第一统一依赖关系图的过程中出现构建失败，通过所述源程序文件执行实际的构建，生成第二统一依赖关系图；以及

通过图并算子将所述第一统一依赖关系图和所述第二统一依赖关系图合并在一起，将合并在一起的统一依赖关系图作为所述修剪后的程序的统一依赖关系图。

7.根据权利要求1所述的虚拟构建脚本的依赖性错误检测方法，其特征在于，所述基于所述统一依赖关系图进行依赖性错误检测，包括：

通过VeriBuild基于所述统一依赖关系图进行依赖性错误检测。

8.一种虚拟构建脚本的依赖性错误检测装置，其特征在于，包括：

文件获取模块，获取待构建的源程序文件及待检测的构建脚本，所述源程序文件指待编译的代码文件，所述构建脚本指用于编译构建源程序文件所需的脚本文件；

程序修剪模块，对所述源程序文件进行修剪，删除所述源程序文件中不影响动态依赖关系的部分，经修剪得到修剪后的程序；

虚拟构建模块，基于所述待检测的构建脚本，通过虚拟构建方法构建所述修剪后的程序的统一依赖关系图；以及

错误检测模块，基于所述统一依赖关系图进行依赖性错误检测。

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

存储器，所述存储器存储执行指令；以及

处理器，所述处理器执行所述存储器存储的执行指令，使得所述处理器执行如权利要求1至7中任一项所述的方法。

10.一种可读存储介质，其特征在于，所述可读存储介质中存储有执行指令，所述执行指令被处理器执行时用于实现如权利要求1至7中任一项所述的方法。

Images