Travis CI 的部署

很早就有体验 Travis CI 持续集成的想法，于是拿 VapourSynth-JincResize 项目试一试。

依赖问题

昨天给 JincResize 项目照猫画虎写了.travis.yml脚本。一开始打算沿用我在 Linux 下编译的模式，基于meson+ninja构建。为此还专门去搜了 Github Issues，从 Issues 上面抄了使用 meson 的.travis.yml脚本。

但等我上传了脚本、部署完成之后才想起，JincResize 项目使用 pkg-config 解决依赖的问题，而配置 pkg-config 需要先编译 VapourSynth…在服务器上编译也不是不行，但这样也太脱裤子放屁了…于是我便想不借助构建工具了，直接用 gcc 编译，反正我的项目结构简单。

直接用 gcc 编译也需要解决 VapourSynth 头文件的依赖，绞尽脑汁想了个略显蛋疼的办法，从 VapourSynth 的官方仓库中下载头文件到服务器，再移到相应位置。之所以这么折腾，而不是把需要的头文件传到 JincResize 项目的仓库中，是因为很多其他 VapourSynth 的 Plugin 项目都不传这类通用头文件不同版本 VapourSynth 头文件对应不同版本的 VapourSynth API，API 版本不同，编译出来的动态链接库没法被 VapourSynth 主程序调用。如果我自己向仓库传了某一版本的头文件，反而可能误导其他人。

然而 VapourSynth 毕竟不是一个小项目，起初想试一下 git 2.25.0 新增的部分克隆功能，只克隆我需要的两个头文件，但我太笨了…不会用。遂用 wget 下载 Release 中打包好的源码（体积毕竟比整个仓库小），然后再解压我想要的文件、移动。

编译器版本问题

Travis CI 服务器用的是 ubuntu 16 + gcc 5，由于 JincResize 项目使用了 C++17 的特殊数学函数（cyl_bessel_j()），需要 gcc 7 及以上版本。好办，直接给服务器装 gcc 7 呗。

话是这么说，而且也部署成功并编译通过了，但我总觉得安装 gcc 7 时要把系统依赖都升级一遍（sudo apt-get upgrade）有点不太环保（虽然 Travis CI 的服务器性能强劲）。于是改了一下代码，当 gcc 版本小于 7 时，用传统的ji()函数，不涉及 C++17。

总算环保地在服务器上编译通过了。

各编译器对 C++ 新特性的支持

（未完待续…）