前言

前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。

构建工具 cmake-toolset 和 curl

首先，curl 是支持多种第三方库作为 HTTP/2 和 HTTP/3（QUIC）算法库的。比如 nghttp3+ngtcp2，或者微软家 msquic，或者Google家 quiche。 其中HTTP/3只能选一个，互相是冲突的。而Google的quiche官方仅有对bazel构建系统的支持，而我的cmake-toolset是cmake生态的。 这里选用 nghttp3+ngtcp2 的组合，主要是为了和其他的模块共享依赖。

前言

最近新项目重新评估了一下protobuf的C/C++ -> Lua binding 方案。之前，使用最广泛的 Lua binding 方案应该是 云风 的 pbc 。但是这个库已经是作者弃坑好多年的状态了。我之前使用 pbc 的时候刚碰上 protobuf 3.0 刚出来，当时打了patch来适配 protobuf 3.0 ，还修复了一些其他问题。这个Patch有些推给了上游，有些因为和上游的某些机制冲突没有推。我了解到的很多其他项目也或多或少的打了自己的Patch，大多数也没往上游推。基本上 pbc 已经处于一个失维的状态，所以这次新项目就干脆来寻求更好，或者说仍然有良好活跃度的解决方案。于是就看向了 upb 。

前言

偷懒了好久没有写分享了，最近的时间也是花费了很多时间大量优化了之前游戏服务器框架和组件的很多细节。其中，相对独立且同时也被其他的项目使用的一个工具则是基于 cmake 和 git 且兼容 vcpkg 的构建系统 cmake-toolset 。之所以要写这么个构建工具主要是要提供比 vcpkg 更宽容的兼容性（没办法我们公司的编译环境比较古老），并且提供更进一步的定制化能力（包含但不限于功能开关和下载源，这些东西 vcpkg 也是很后期才有了个初步的支持）。那么先来记录一下构建系统适配过程中的一些问题吧。

背景

对大型项目来说，必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言，依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程，比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便，也不容易定制组件。我使用 cmake 比较多，所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils，里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。

最近看了下最新版本的cmake的文档，很惊喜地发现他已经支持直接设置Android和OSX的一些变量了，然后有瞄了一眼NDK，发现里面现在也停工官方的cmake支持。