2020-09-16 SSH到开发机 git项目代码 BLADE-Build编译

使用MobaXterm（开源SSH软件）登录堡垒机。

堡垒机username是erp账号，端口80。（本地主机连接堡垒机，用堡垒机登录开发机。（由于安全等因素，登录开发机时需要先登录跳板机，然后在跳板机上再实际连接开发机））

把远程仓库代码下载到本地

配置git，生成ssh key，添加到gitlab。

git config --global user.name "youremail"
git config --global user.email "youremail@domain.com"
ssh-keygen -t rsa -C "描述当前的是哪个用户"
//三次回车
//把提示目录下的pub ssh key，添加到gitlab

git clone git@XXX.git                  //从远程仓库clone下来代码
git submodule update --init --recursive     //把子模块也拉下来
//以上两句可以用一句 git clone git@XXX.git --recursive 替代

submodule子模块是指这个库用了其他的github库，代码不直接存在本库中，本库中只有一个快捷方式，只有下载到本地的时候才会把子模块也下载过来。
rm命令被保护了起来，使用要用/bin/rm，比如删除gateway文件夹要用/bin/rm -r gateway

使用blade-build构建

blade是腾讯的一款开源现代化构建工具（c++常见的构建工具make等）。
https://github.com/chen3feng/blade-build

优势：
1.编写简单。描述的是需要什么而不是怎么做，因此不需要开发人员掌握gcc的命令行、make奇奇怪怪的自动变量。
2.自动分析间接的依赖（头文件里包含的头文件，库依赖库），make是不支持的。头文件变化时，所有直接和间接包含它的源文件都会被自动找出来，进行构建。而不受影响的源文件则无需重复构建，真正实现了增量构建。对于库和链接也是一样。
3.把整个项目看作一个有机的整体（Blade提倡从项目根目录开始定位文件和库（#include 从根开始写）），而不是很多个小的块块（不同的小块用相对路径之类的当然可能重名），就每个都有自己的唯一路径，不会重名。
4.其他
增量构建(指重新构建受影响的）/并行构建/支持ccache缓存构建结果/distcc分布式构建。
Blade在代码树的任意子目录下都能构建，其依赖会被自动找出来构建，不多不少，确保正确性。
动态库部署是灾难，所以大量用静态的。
Blade内置 debug/release 两种构建类型，32/64位两种目标平台。
构建进度显示被大幅度简化为做了什么而不是在怎么做。

使用：
Blade要求项目源代码有一个明确的根目录，这个目录我们称为工作空间，一个工作空间内任何绝对路径引用（"//"开头）都从这个目录开始。我们建议C++ 中的 #include 的路径都从这个目录开始写起，比如 #include “common/io/file.h” 而不是用incs选项后，再不带路径地 #include “file.h” , 这样有效地避免重名造成的问题。

编写BUILD文件 2020/9/17
https://github.com/chen3feng/blade-build/blob/master/doc/zh_CN/build_file.md
Blade 通过一系列的名字为 “BUILD” 的文件（文件名全大写）构建。
Blade用一组target函数来定义目标，这些target的通用属性有：
name: 字符串，和路径一起成为target的唯一标识，也决定了构建的输出命名
srcs: 列表或字符串，构建该对象需要的源文件，一般在当前目录，或相对于当前目录的子目录中
deps: 列表或字符串，该对象所依赖的其它targets
visibility: 列表或字符串，控制该目标对哪些其他目标可见，特殊值 ‘PUBLIC’ 表示对所有目标可见
我们也提供了一个 glob 函数通过通配符来获取源文件列表。
deps的允许的格式：
“//path/to/dir/:name” 其他目录下的target，path为从BLADE_ROOT出发的路径，name为被依赖的目标名。看见就知道在哪里。
“:name” 当前BUILD文件内的target， path可以省略。
“#name” 系统库。直接写#跟名字即可，比如#pthread，#z分别相当于链接命令行上的-lpthread和-lz，但是会被传递给依赖这个库的其他目标。
cc_xxx代表构建的是c++目标（因为blade-build能构建的不止c++，还有java，pyhton等）。里边看不懂的属性到https://github.com/chen3feng/blade-build/blob/master/doc/zh_CN/build_rules/cc.md查。比如extra_cppflags是用户定义的额外的C/C++编译flags。
cc_library()
C++库目标
cc_binary()
C++可执行文件目标
cc_test()
相当于cc_binary，再加上自动链接gtest（google发布的C++单元测试框架）和gtest_main。
testdata=[]
在name.runfiles里建立symbolic link指向工程目录的文件，目前支持以下几种形式：
‘file’ 在测试程序中使用这个名字本身的形式来访问
‘//your_proj/path/file’ 在测试程序中用"your_proj/path/file"来访问。
(’//your_proj/path/file’, “new_name”) 在测试程序中用"new_name"来访问

例子

文件目录结构：
project
　BLADE_ROOT（空文件，只为了告诉blade这是根）
　source
　　test.cpp
　　BUILD

BUILD
注意：srcs只能用相对路径
deps可以用相对可以用从BLADE_ROOT开始的绝对路径
---------------------
cc_binary(
    name = 'demo_test',
    srcs = [
        'test.cpp',
    ],
)
----------------------
在这个工程的任意路径使用blade build命令，就可以进行全工程编译了
编译完成后就可以进入对应的编译完成的路径使用./demo_test执行了

注意：
.h不用被编译为什么目标，在cpp的#include里就用了。
.cpp被编译为库或者可执行文件。
只有头文件就不用写deps了，blade会让工程知道#include是从BLADE_ROOT开始找路径的。

扩展

Linux系统下单个cpp文件的编译执行

C++编译g++ Hello.cpp -o Hello -o代表output
C++执行./Hello

---

BUILD文件几种目标的写法
------------------------------------------------
cc_binary(
    name='hhh',                        # 生成的target会叫做hhh
    srcs=[
        'server/main.cpp',             # 构建该对象需要的源文件
    ],
    deps=[
        ':ttt',                        # 在本BUILD中被构建的其他target，本例中就是下边的ttt
        '//gw_base/proto:ad_request',  # 其他目录下的target，从BLADE_ROOT出发的路径
        '//proto:ad_request',
    ]
)
cc_library(
    name='ttt',
    srcs=[……],
    extra_cppflags=[
        '-fno-access-control',
        '-DUT',
    ],
    deps=[……]
)

cc_test(
    name='search_test',
    srcs=[……],
    extra_cppflags=[……],
    deps=[……],
    testdata = [
        ('//ut/traffic/search/resp.txt', 'resp.txt'),
        ('//ut/traffic/search/fill_data.txt', 'fill_data.txt'),
    ]
)

输出
1.指定生成 32/64 位结果也很简单，加上 -m32/64即可。 默认生成 release 版本的结果，如果生成 debug 版的，加上 -p debug 即可。
2.在新建的build目录下，生成的文件一律按原来的层次和名称在这个目录里，不会污染源代码目录。