皮皮网
皮皮网

【自适应商城源码】【私单信用系统源码】【cola4.0源码分析】clang tidy 源码

时间:2024-12-27 13:53:46 来源:php 开源 卡商 源码

1.从零开始构建向量数据库:Milvus 的源码编译安装(一)
2.一文带你梳理Clang编译步骤及命令

clang tidy 源码

从零开始构建向量数据库:Milvus 的源码编译安装(一)

       在知乎上新开了关于“向量数据库”内容的专栏[1],本文将详细介绍如何在x和ARM架构的Linux系统上编译安装开源项目Milvus,这个项目由Linux Foundation AI & Data基金会支持,常与Weaviate和Elasticsearch相提并论[2][3]。

       由于Milvus主要在GitHub进行开发,中文网络中关于编译安装的自适应商城源码教程很少,且大多是过时的1.x版本资料,而Milvus的版本迭代迅速,目前主要提供Docker容器安装,本地开发者或追求透明度的开发者可能会觉得不够友好。本文将从头开始,逐步引导你进行编译安装。

       前置准备

       在开始前,需要确保操作系统、开发环境和必要的依赖已经准备妥当。Linux作为主力生产环境,本文将重点介绍在Ubuntu上编译。macOS和Windows上的步骤类似,但这里主要针对Linux。私单信用系统源码

       操作系统

       推荐使用Ubuntu,无论是服务器、容器基础镜像,还是个人笔记本。具体配置和安装细节可以参考我在其他文章中介绍的《笔记本上搭建Linux学习环境》[6]。

       开发环境

       Milvus主要使用Golang编写,同时包含C++代码。确保Golang和C++环境可用,参考《搭建Golang开发环境》[8],并注意Milvus官方推荐的版本。

       源码获取

       获取Milvus源码有两种方式:Git Clone或下载压缩包,其中Git Clone可能需要借助国内镜像加速。具体步骤包括设置代码仓库的上游,确保代码同步。

       编译基础依赖

       项目依赖OpenBLAS加速向量计算,详细安装步骤在《走进向量计算:OpenBLAS编译》[]中有详述。

       准备构建依赖:cmake

       确保cmake版本至少为3.,Ubuntu .需手动安装,cola4.0源码分析而Ubuntu .可直接使用apt。不同版本可能有差异,注意官方文档推荐的版本。

       额外依赖:clang-format和clang-tidy

       项目代码中需要clang-format和clang-tidy,Ubuntu .和.的安装方式各有不同,务必安装正确版本以保持和官方构建一致。

       编译 Milvus

       切换到 Milvus 代码目录,执行make命令编译。整个过程可能耗时,但完成后将在./bin/目录下找到可执行文件。

       总结

       本文详细介绍了在Ubuntu .和.环境中编译安装Milvus的步骤,包括操作系统、开发环境和依赖的安装。后续文章将深入探讨容器镜像构建优化以及在MacOS上的安装指南。

       期待你的反馈,如果觉得有用,请点赞和分享。如有任何问题或需要更新,筹码峰持股线源码请关注后续内容更新,感谢支持!

一文带你梳理Clang编译步骤及命令

       摘要: 本文简单介绍了Clang编译过程中涉及到的步骤和每个步骤的产物,并简单分析了部分影响预处理和编译成功的部分因素。

       本文简单介绍部分Clang和LLVM的编译命令。更关注前端部分(生成 IR 部分)。

1. Clang编译步骤概览

       我们可以使用命令打印出来Clang支持的步骤,如下:

clang-ccc-print-phasestest.c+-0:input,"test.c",c+-1:preprocessor,{ 0},cpp-output+-2:compiler,{ 1},ir+-3:backend,{ 2},assembler+-4:assembler,{ 3},object5:linker,{ 4},image

       根据上面的介绍,可以根据每一部分的结果,分为5个步骤(不包含上面的第0步):preprocessor、compiler、backend、assembler、linker等。

       具体到 Clang 中每一步骤生成的结果文件。我们可以使用下面的示意图来表示:

       说明:上面的示意图以Clang编译一个C文件为例,介绍了Clang编译过程中涉及到的中间文件类型:

       (1) test.c 为输入的源码(对应步骤 0);

       (2) test.i 为预处理文件(对应步骤 1 的输出,cpp-output 中,阜新企业网站源码cpp 不是指 C++ 语言,而是 c preprocessor 的 缩写);

       (3) test.bc 为 bitcode文件,是clang的一种中间表示(对应步骤 2 的输出);

       (4) test.ll 为一种文本化的中间表示,可以打开来看的(对应步骤 2 的输出, 和 .bc 一样都是中间表示,可以相互转化);

       (5) test.s 为汇编结果(对应步骤 3 的输出);

       (6) test.o 为单文件生成的二进制文件(对应步骤 4 的输出);

       (7) image 为可执行文件(对应步骤 5 的输出)。

       注意:示意图画的也并不完整,如下介绍:

       (1) 箭头所指的方向,表示可以从一种类型的文件,生成箭头所指的文件类型;

       (2) 图中箭头并没有画完,比如可以从 test.c 生成 test.s, test.o 等。如果将上面的示意图当做一种 有向图,那么基于 箭头 所指的方向,只要 节点能连接的点,都是可以做转换的;

       (3) 图中的实线和虚线,只是表示本人关心的Clang编译器中的内容,并没有其他的含义,本文也只介绍图中实线部分的内容,虚线部分的内容不做介绍。

2. 转换命令集合

       下面介绍部分涉及到上面步骤的转换命令:

#1..c->.iclang-E-ctest.c-otest.i#2..c->.bcclang-emit-llvmtest.c-c-otest.bc#3..c->.llclang-emit-llvmtest.c-S-otest.ll#4..i->.bcclang-emit-llvmtest.i-c-otest.bc#5..i->.llclang-emit-llvmtest.i-S-otest.ll#6..bc->.llllvm-distest.bc-otest.ll#7..ll->.bcllvm-astest.ll-otest.bc#8.多bc合并为一个bcllvm-linktest1.bctest2.bc-otest.bc

       上面列出了一部分Clang不同文件直接转换的命令(和第 1 部分的 示意图 序号匹配,还是只关心前端部分)。只是最后增加了一个将多个 bc 合并为一个 bc file 的命令。

3. 查看Clang AST结构

       我们可以通过如下的命令查看源码的AST结构:

clang-Xclang-ast-dump-ctest.c

       打印出来的AST信息,其实是预处理之后展开的源码信息,源码的AST内容在打印出来的内容的最下面。

       如下面的代码:

#include<stdio.h>intmain(){ printf("hello");return0;}

       打印出来的部分AST(仅根当前文件内容匹配部分)如下:

       头上的头文件引用等已经展开,没有了,但是下面的 main 函数定义,则如上面的 FunctionDecl 所示,并且给出了 代码中的位置。这里就不详细分析AST的结构了,写几个例子比对一下就很容易理解。

4. 编译正确性的影响因素

       当前,很多静态代码分析工具,都采用 Clang 和 LLVM 作为底座来开发静态代码分析工具。Clang自己也有 clang-tidy 工具可以用来做 C/C++ 语言的静态代码分析。为了能够用 Clang 和 LLVM 来成功分析 C/C++ 代码,需要考虑如何成功使用 Clang 和 LLVM 来编译 C/C++ 代码。可以考虑的是,成功生成 bc file,是静态代码分析的基础操作。

4.1 影响预处理结果的因素

       预处理过程,作用跟名字一样,都可以不当做编译的一个步骤,而是编译的一个预处理操作。我们说得再直白一点儿,其实就是做了一个文本替换的活儿,就是对 C/C++ 代码中的 预处理指令 进行处理。预处理指令很简单,比如 #include,#define 等,都是预处理指令(可以参考:/en-us/cpp/preprocessor/preprocessor-directives?view=msvc-,或者google下,很多介绍的)。

       如果程序中没有预处理指令,即使我们随便瞎写的代码,预处理也一般不会有问题,如下的代码(main.c):

abcdef

       我们仍然可以正确得到 预处理结果:

#1"main.c"#1"<built-in>"1#1"<built-in>"3#"<built-in>"3#1"<commandline>"1#1"<built-in>"2#1"main.c"2abcdef

       为了成功执行预处理执行,很容易理解,就是可以对程序中的所有的 预处理指令 进行处理。比如:

       (1) #include,依赖了一个头文件,我们能不能成功找到这个头文件;

       (2) #define,定义了一个宏,在程序中定义宏的时候,我们能不能准确找到宏(找到,还必须准确);

       (3) 其他指令。

4.2 影响IR生成因素

       这一步是针对上一步生成的预处理指令,进行解析的操作。这一步才是最关键的,归根结底,我们需要保证一点:使Clang编译器可以正确识别出来代码中内容表示的语法结构,并且接纳这种语法结构!

       举一些简单例子:

       (1) -std 用来指定支持的 C/C++ 标准的,如果我们没有指定,那么就会采用 Clang 默认的标准来编译,就可能导致语法不兼容;

       (2) -Werror=* 等参数,可能将某些能识别的语法,给搞成错误的使用;

       (3) 其他的部分,跟语法识别的参数;

       (4) 还有一部分的语法,可能 Clang 自始至终就没有进行适配,这种就要考虑修改源码了。

4.3 链接相关因素

       在真正编译中,如果链接有问题,那就会失败,但是在静态代码分析中,链接有失败(无法链接)或者错误(不相关的给链接在一起),可能多点儿分析误报或者漏报,一般不会导致分析失败。这类问题,影响的不是中间表示的生成,而是分析结果(影响跨文件的过程间分析,影响对built-in函数的建模等)。

       一般,链接命令的捕获,target信息配置等,会影响这部分的能力。当然,也跟你实现的工具有关(如果实现的工具,就没有跨文件的能力,这部分内容也没啥影响)。

       作者:maijun。

更多内容请点击【时尚】专栏