ccache

在lib/main.sh当中 13 if [[ $(basename $ 0 ) == main.sh ]]; then 14 echo " Please use compile.sh to start the build process " 15 exit - 1 16 fi 17 18 # default umask for root is 022 so parent directories won ' t be group writeable without this 19 # this is used instead of making the chmod in prepare_host() recursive 20 umask 002 21 22 # destination 23 DEST=$SRC/ output 24 25 TTY_X=$(($(stty size | awk ' {print $2} ' )- 6 )) # determine terminal width 26 TTY_Y=$(($(stty size | awk ' {print $1} ' )- 6 )) # determine terminal height 27 13-16行，由于 main.sh脚本的执行需要在compile.sh内 被调用，不可以直接通过lib/main.sh

Zilliz 公司以 “重新定义数据科学” （Reinvent Data Science）为愿景，专注于研发利用新一代异构计算的开源数据科学软件。随着各项目的蓬勃发展，我们对于持续集成、持续交付、持续部署（CI/CD）都提出了更高的要求。本文是 CI/CD 系列的开篇，重点介绍持续集成的编译优化实践。 ​ | 问题与挑战 在编译构建过程中我们遇到以下几个问题： 1) 编译时间较长 项目每天都要完成上百次的代码集成，面对几十万行的代码量，开发人员进行小的 feature 改动都有可能会导致工程的全量编译，需要花费超过一个小时或者更长时间，显然让人难以接受。 2) 编译环境复杂 项目代码在不同的操作系统（CentOS、Ubuntu 等）、底层依赖库（GCC、LLVM、CUDA 等）、硬件架构等环境下进行编译，并且各编译环境下生成的编译产物都很有可能无法在其他平台下使用。 3) 项目依赖关系复杂 当前项目编译所涉及的各功能组件依赖以及第三方依赖不下三四十个，项目发展时常带来依赖关系的变动，难免会遇到依赖冲突问题。依赖之间的版本控制过于复杂，更新依赖版本容易导致影响其他组件业务。 4) 第三方依赖下载缓慢或无法下载 网络延迟或者第三方依赖仓库不稳定等问题所导致资源下载缓慢或访问失败，严重影响代码集成构建。 | 主要思路 对项目的依赖关系进行解耦。将依赖关系复杂的组件进行拆分

​ 缘起 Nebula Graph 最早的自动化测试是使用搭建在 Azure 上的 Jenkins ，配合着 GitHub 的 Webhook 实现的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运行相应的 UT 测试，效果如下： 因为是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且任务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在考虑寻找替代的方案，准备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。 调研了一圈现有的产品主要有： TravisCI CircleCI Azure Pipeline Jenkins on k8s（自建） 虽然上面的产品对开源项目有些限制，但整体都还算比较友好。 鉴于之前 GitLab CI 的使用经验，体会到如果能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出世，Nebula Graph 便勇敢的入了坑。 这里简单概述一下我们在使用 GitHub Action 时体会到的优点： 免费。开源项目可以免费使用 Action 的所有功能，而且机器

缘起 Nebula Graph 最早的自动化测试是使用搭建在 Azure 上的 Jenkins ，配合着 GitHub 的 Webhook 实现的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运行相应的 UT 测试，效果如下： 因为是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且任务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在考虑寻找替代的方案，准备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。 调研了一圈现有的产品主要有： TravisCI CircleCI Azure Pipeline Jenkins on k8s（自建） 虽然上面的产品对开源项目有些限制，但整体都还算比较友好。 鉴于之前 GitLab CI 的使用经验，体会到如果能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出世，Nebula Graph 便勇敢的入了坑。 这里简单概述一下我们在使用 GitHub Action 时体会到的优点： 免费。开源项目可以免费使用 Action 的所有功能，而且机器 配置较高

ccache可以在重复编译lineage的时候，加快编译速度 如果是3.7.7-1版本，编译正常 如果升级到3.7.8-1版本，可能会导致如下出错提示: ccache error: internal error of format 在遇到编译出错的时候，认真查看错误提示，再结合最近的系统变化情况进行分析，一定是可以解决问题的 3.7.7-1 -> 3.7.8-1 来源： oschina 链接： https://my.oschina.net/u/222749/blog/3213218

前言 历经2天的折腾总算把OpenJDK给编译成功了，要说为啥搞这个，还得从面试说起，最近出去面试经常被问到JVM的相关东西，总感觉自己以前学的太浅薄，所以回来就打算深入学习，目标把《深入理解Java虚拟机》这个本书要啃下来。接下来问题来了，读个这个书的人都知道这个书的第一章就是讲如何编译自己的JDK，书上的东西看着简单，自动动手另外是一回事，经过这么几天折腾体会很深刻，做技术的，还是要踏踏实实的一步步来。好高骛远是大忌。废话不多说，下面给出自己编译过程 环境要求 系统：CentOS7 编译源码版本：OpenJDK-8u40 下载地址：链接: https://pan.baidu.com/s/1LRP_67uBezBqn-gfStlH-A 密码:o65r Bootstrap JDK：Oracle JDK1.7.0_75 下载地址：链接: https://pan.baidu.com/s/1sKuXkNcnjJp-qCe5_4_qVw 密码:n1fq ccache版本：3.14 下载地址：链接: https://pan.baidu.com/s/1-qvxAMkaJS1ASSVbNZHkFA 密码:m9fj 编译所以需要的安装包以及系统文件下载地址： 链接: https://pan.baidu.com/s/1Jb1iSSmutZKLmzjncIdRXA 密码:myk9 安装前准备 yum

基于迅为iTOP-3399 开发板 2.1 装 安装 d android 源码依赖包 登录进 Ubuntu 系统，输入“ctrl+alt+t”，打开超级终端，使用“su root” 命令 ，切换到 root 用户，如下图： 2.1.1 安装 JDK Android8.1 系统编译依赖于 JAVA 8。编译之前需安装 OpenJDK。安装命令 如下： sudo apt-get install openjdk-8-jdk 执行结果，如下图： 2.1.2 装 安装 d android 源码依赖包 使用如下命令安装所需的软件包： sudo apt-get update sudo apt-get install git-core gnupg flex bison gpe RF libsdl1.2-dev libwxgtk3.0-dev build-essen ti alzip curl zlib1g-dev gcc-multilib g++-multilib genromfs libc6-dev-i386 libncurses5-devx11proto-core-dev libx11-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip lsb-corelib32z1-dev lib32ncurses5-dev texinfo