Kong 中 PCRE2 的 Bazel 构建机制详解：从版本锁定到 nginx --with-pcre-jit 的完整依赖链

Kong 中 PCRE2 的 Bazel 构建机制详解从版本锁定到 nginx --with-pcre-jit 的完整依赖链【免费下载链接】kong The API and AI Gateway项目地址: https://gitcode.com/GitHub_Trending/ko/kong本篇以 build/openresty/pcre/README.md 为核心系统讲解 Kong 源码构建体系中 PCRE2 正则引擎的 Bazel 集成方案。读完本文你将理解 Kong 如何从上游rules_foreign_cc示例改造出可复用的第三方依赖构建规则如何在.requirements中锁定 PCRE2 版本与 SHA256 校验值以及编译出的静态库如何被 OpenRestynginx通过--with-pcre-jit消费——这是理解 Kong 高性能路由匹配正则路由底层依赖构建的关键。一、文档背景Kong 为何要自己管理 PCRE 构建build/openresty/pcre/README.md 虽然篇幅很短但它记录了 Kong 构建体系中一个关键的工程决策Kong 没有直接复用 Bazel 官方rules_foreign_cc项目中现成的第三方 C/C 库示例而是基于该项目的示例做了针对性改造改造点有两条版本号不再硬编码在构建规则里而是从版本清单文件读取README 中写作requirements.txt在本仓库实际落地为 build/.requirementsbuild_file路径更新为//build/openresty目录下的新位置即 build/openresty/pcre/BUILD.pcre.bazel。这个决策背后的原因是Kong 的构建体系需要对 Nginx、LuaJIT、PCRE、OpenSSL、Brotli 等十余个底层依赖做统一、可复现的版本锁定。Kong 运行在 nginxOpenResty之上nginx 的正则能力location ~、rewrite、路由匹配完全依赖 PCRE 库。Kong 的 changelog 清晰地记录了这条依赖线的演进3.7.0 将 PCRE 从遗留的 libpcre 8.45 升级到libpcre2 10.43见 bump-pcre.yml3.8.0 继续升级到PCRE2 10.44见 bump-pcre.yml当前未发布版本已升级到PCRE2 10.45见 bump-pcre.yml。PCRE2 相比 PCRE 1 是重大重写API、内部结构均不兼容Kong 选择跟随 nginx 上游完成迁移而迁移能否在 x86_64/aarch64、Linux/macOS、原生/交叉编译等全矩阵下稳定复现正是这套 Bazel 规则要解决的问题。二、版本锁定.requirements如何成为唯一事实来源README 提到的第一条改造——从 requirements 文件读取版本——在仓库中的实现链路是1. 版本清单文件build/.requirements 中显式锁定PCRE10.45 PCRE_SHA2560e138387df7835d7403b8351e2226c1377da804e0737db0e071b48f07c9d12ee2. 绑定仓库读取该文件build/kong_bindings.bzl 通过repository_rule在分析阶段读取kong//:.requirements第 7 行ctx.read(Label(kong//:.requirements))解析每一行KEYVALUE后生成variables.bzl文件其中第 69 行写出KONG_VAR { ... }字典。这样所有 Bazel 规则都能以KONG_VAR[PCRE]、KONG_VAR[PCRE_SHA256]的形式引用版本而无需知道文件细节。3. 消费方build/openresty/pcre/pcre_repositories.bzl 第 8 行直接version KONG_VAR[PCRE]。这种单点锁定设计的收益升级 PCRE2 只需改.requirements两行版本 SHA256配合 changelog 提交即可完成一次受控升级且 SHA256 校验保证了供应链完整性。三、源码获取pcre_repositories仓库规则pcre_repositories.bzl 是一个标准的http_archive包装核心逻辑第 7–19 行def pcre_repositories(): version KONG_VAR[PCRE] maybe( http_archive, name pcre, build_file //build/openresty/pcre:BUILD.pcre.bazel, strip_prefix pcre2- version, sha256 KONG_VAR[PCRE_SHA256], urls [ https://github.com/PCRE2Project/pcre2/releases/download/pcre2- version /pcre2- version .tar.gz, ], )要点解析maybe包装确保该仓库规则在重复调用时幂等openresty_repositories()之外的其他入口也可能触发它build_file参数这正是 README 提到的第二条改造——把 BUILD.pcre.bazel 作为外挂 BUILD 文件注入下载并解压后的 PCRE2 源码树中让一份没有 Bazel 支持的纯 C 项目立刻变成可构建的外部仓库仓库标签为pcrestrip_prefix pcre2- version源码包顶层目录会随版本变化pcre2-10.45/用版本号动态拼接保证剥离前缀始终正确urls指向 PCRE2 官方项目的 release 渠道与 SHA256 成对使用。该仓库规则由 build/openresty/repositories.bzl 中的openresty_repositories()统一编排pcre_repositories()是整个 OpenResty 依赖列表的第一个调用第 33 行随后依次是 OpenSSL、simdjson_ffi、atc_router、wasmx、brotli、snappy、ada 等形成完整的底层依赖清单。四、编译规则BUILD.pcre.bazel中的 cmake 目标注入源码树的 BUILD.pcre.bazel 是整套规则的核心它用rules_foreign_cc的cmake规则构建 PCRE2# pcre cmake detects cross compile automatically cmake( name pcre, build_args [ --, # - Pass remaining options to the native tool. -j KONG_VAR[NPROC], ], cache_entries { CMAKE_C_FLAGS: ${CMAKE_C_FLAGS:-} -fPIC, PCRE2_SUPPORT_JIT: ON, # enable JIT support for pcre2_jit_compile PCRE2_BUILD_PCRE2GREP: OFF, # we dont need the cli binary PCRE2_BUILD_TESTS: OFF, # test doesnt compile on aarch64-linux-gnu (cross) CMAKE_INSTALL_LIBDIR: lib, # force distros that uses lib64 (rhel family) to use lib }, lib_source :all_srcs, out_static_libs [libpcre2-8.a], visibility [//visibility:public], )逐条说明各参数的工程含义参数作用PCRE2_SUPPORT_JIT: ON启用 JIT 编译支持生成pcre2_jit_compile能力。nginx 正则热点路径路由匹配可受益且必须与 OpenResty 侧--with-pcre-jit配置配套见第五节PCRE2_BUILD_PCRE2GREP: OFF不构建 pcre2grep 命令行工具网关只需要库PCRE2_BUILD_TESTS: OFF源码注释说明原因PCRE2 自带测试在aarch64-linux-gnu交叉编译环境下无法编译因此关闭以避免交叉构建失败CMAKE_C_FLAGS: ... -fPIC追加-fPIC位置无关代码标志保证静态库可被动态链接进最终产物CMAKE_INSTALL_LIBDIR: lib强制安装到lib而非lib64解决 RHEL 系发行版默认lib64导致的目录不一致问题build_args中的--与-j NPROC--之后的参数透传给 cmake 底层构建工具make/ninjaNPROC同样来自.requirements绑定实现并行编译out_static_libs [libpcre2-8.a]声明产物为 8 位字符集的 PCRE2 静态库供下游按名称消费文件顶部的注释# pcre cmake detects cross compile automatically点出另一个设计事实PCRE2 的 CMake 脚本能自动识别交叉编译目标host ≠ target因此 Kong 无需为 aarch64/x86_64 交叉场景额外传CMAKE_SYSTEM_NAME等变量交叉构建的适配成本被上游工具链吸收。同目录的 BUILD.bazel 则用于声明本包内.bzl/.bazel文件在 Kong 主仓库侧的可见性。五、消费端OpenResty 如何把 PCRE 编进 nginxPCRE 静态库最终被 build/openresty/BUILD.openresty.bazel 中的configure_make目标openresty消费体现在三处1. configure 选项启用 JIT第 127 行CONFIGURE_OPTIONS [ --with-pcre-jit, ...这与第四节PCRE2_SUPPORT_JITON形成闭环PCRE 库侧编译了 JIT 能力nginx 侧再以--with-pcre-jit打开对应的运行时开关。2. 头文件与库路径指向pcre的产物第 149、152 行--with-cc-opt\-I$$EXT_BUILD_DEPS/pcre/include\, --with-ld-opt\-L$$EXT_BUILD_DEPS/pcre/lib\,$$EXT_BUILD_DEPS是rules_foreign_cc提供的变量指向依赖目标安装目录pcre子目录即上一节cmake规则 install 后的include/lib/其中lib/正是CMAKE_INSTALL_LIBDIRlib保证的目录。同一组--with-cc-opt/--with-ld-opt也用于 OpenSSL 和 LuaJIT体现了 Kong 对所有底层 C 依赖统一采用外部静态库 路径注入的集成模式。3. 声明式依赖第 327–330 行deps [ openresty//:luajit, openssl, pcre, ]通过deps声明后Bazel 会自动把pcre加入执行顺序与远程缓存的 action key保证 PCRE 先于 OpenResty 构建且版本变化.requirements改动会正确触发重编译。六、构建与验证路径从源码结构看开发者可用的验证入口包括单独构建 PCRE 目标由于BUILD.pcre.bazel被注入到外部仓库实际构建标签是pcre//:pcrecmake规则名产物为libpcre2-8.a全链路构建openresty//:openrestyconfigure_make规则名见 BUILD.openresty.bazel 第 273–349 行会按依赖顺序先构建luajit、openssl、pcre再执行 OpenResty 的configure make make install调试辅助目标同文件第 351 行起定义了dev-just-make生成规则用于在已 configure 的构建目录中快速重跑make make install适合修改 Nginx C 代码后的迭代验证。完整的 Bazel 构建体系说明包括交叉编译工具链、KONG_VAR绑定机制等可在 DEVELOPER.md 中继续查阅其中OpenResty system, including Nginx, LuaJIT, PCRE, etc.一节专门描述了该子系统的定位。PCRE 的许可文本也已按合规要求收录于仓库根目录的 COPYRIGHT 文件中。七、小结build/openresty/pcre/README.md 记录的是一次典型的上游示例 → 生产化改造Kong 在rules_foreign_cc官方示例基础上把版本信息外置到 build/.requirements当前锁定PCRE2 10.45并附 SHA256把构建文件迁到 build/openresty/pcre/ 统一管理。围绕这份 README整条链路是kong_bindings.bzl 读取.requirements生成KONG_VARpcre_repositories.bzl 按版本拉取 PCRE2 源码并注入 BUILD.pcre.bazelcmake规则以 JIT ON、关闭 pcre2grep 与测试、强制lib目录等参数产出libpcre2-8.aBUILD.openresty.bazel 通过--with-pcre-jit、-I/-L $$EXT_BUILD_DEPS/pcre/...与deps [pcre]将其集成进 nginx 可执行文件。这套机制让 Kong 在保持与 nginx/OpenResty 上游正则能力同步演进PCRE 8 → PCRE2 10.x的同时获得了跨平台、可复现、带完整性校验的底层依赖构建能力。【免费下载链接】kong The API and AI Gateway项目地址: https://gitcode.com/GitHub_Trending/ko/kong创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考