夜雨聆风
PG源码编译之内置 vs 外置方式
1.1. 定义
在源代码目录内部直接进行编译，所有构建生成的文件都混在源代码目录中。
1.2. 典型结构
postgresql-18.0/
├── src/# 原始源代码
├── configure# 配置脚本
├── Makefile# 构建后生成的
├── *.o# 构建后生成的目标文件
├── *.so# 构建后生成的库文件
└── …# 构建产物与源代码混在一起
1.3. 操作步骤
# 1. 进入源码目录
cd postgresql-18.0
# 2. 配置（在源码目录内）
./configure –prefix=/usr/local/pgsql
# 3. 编译（在源码目录内）
make
# 4. 安装
sudo make install
1.4. 优点
1.简单直接：不需要额外管理构建目录
2.路径处理简单：所有路径都是相对的，不易出错
3.传统方式：许多项目默认采用的方式
1.5. 缺点
1.污染源码：生成文件与源代码混在一起
2.清理困难：需要小心清理，可能误删源码
3.版本控制混乱：git status 会显示大量无关文件
4.不支持多配置：无法同时为不同配置构建
5.开发者不友好：影响源代码阅读和搜索
二、pg源码外置编译（Out-of-source Build）
2.1. 定义
在源代码目录外部创建独立的构建目录，保持源代码目录干净。
2.2. 典型结构
project/
├── postgresql-18.0/# 干净的源代码目录（只读）
│├── src/# 原始源代码
│├── configure# 配置脚本
│└── …# 其他源文件
│
└── build-postgresql/# 独立的构建目录
├──Makefile# 配置生成的构建文件
├──*.o# 所有构建产物
├──*.so# 库文件
└──…# 只包含构建相关文件
2.3. 操作步骤
# 1. 创建独立构建目录（在源码目录外）
mkdir build-postgresql
cd build-postgresql
# 2. 使用相对或绝对路径指向源码配置脚本
../postgresql-18.0/configure –prefix=/usr/local/pgsql
# 或者使用绝对路径
# /path/to/postgresql-18.0/configure –prefix=/usr/local/pgsql
# 3. 编译（在构建目录内）
make
# 4. 安装
sudo make install
2.4. 高级外置编译示例
# 创建多个不同配置的构建目录
mkdir build-release build-debug build-coverage
# 发布版本构建
cd build-release
../postgresql-18.0/configure \
–prefix=/usr/local/pgsql-release \
–with-openssl\
–with-python
# 调试版本构建
cd../build-debug
../postgresql-18.0/configure \
–prefix=/usr/local/pgsql-debug \
–enable-debug\
–enable-cassert
2.5. 优点
1.源码纯净：源代码目录保持干净，便于版本控制
2.多配置支持：可同时构建不同配置（调试版、发布版等）
3.清理简单：删除构建目录即可彻底清理
4.开发友好：方便源代码阅读和搜索
5.并行构建：可同时进行多个构建而不冲突
6.便于分发：源代码可打包分发，不含构建产物
2.6. 缺点
1.路径复杂：需要正确指向源码目录
2.学习成本：对新手可能不够直观
3.额外磁盘空间：需要单独的构建目录空间
三、两者对比总结
四、推荐实践
4.1. 个人开发/测试
# 使用外置编译，保持源码干净
mkdir ~/pg-build
cd ~/pg-build
/path/to/postgresql-src/configure –enable-debug
make -j$(nproc)
4.2. 持续集成（CI）环境
# CI 脚本示例
git clone https://github.com/postgres/postgres.git
mkdir build && cd build
../postgres/configure –prefix=/tmp/pg-install
make-j4
make check
4.3. 多版本测试
# 为不同版本创建不同构建目录
for version in 15 16 17 18;do
tar-xzf postgresql-$version.0.tar.gz
mkdir build-pg$version
cd build-pg$version
../postgresql-$version.0/configure –prefix=/opt/pg$version
make -j$(nproc)
sudo make install
cd..
done
4.4. 从内置编译迁移到外置编译
# 1. 清理旧的构建
cd postgresql-src
make distclean
# 2. 创建外置构建目录
mkdir ../build-pg
cd ../build-pg
# 3. 重新配置构建
../postgresql-src/configure [options]
4.5. 常见问题解决
# 如果 configure 找不到文件
# 使用绝对路径
`pwd`/../postgresql-src/configure
# 或使用相对路径（确保正确）
../../path/to/source/configure
# 检查配置是否正确
../postgresql-src/configure –help|grep prefix
4.6. Makefile 中的支持
PostgreSQL 的构建系统原生支持外置编译，但在执行 make 命令时需要注意：
# 在外置构建目录中，这些命令正常工作
make
make check
make install
# 但有些命令可能需要指定源码目录
make -C ../postgresql-src some-target
五、结论
对于 PostgreSQL 开发者和贡献者，强烈推荐使用 外置编译，因为它：
1.保持代码库清洁，便于版本管理
2.支持并行多配置测试
3.符合现代软件开发实践
对于 一次性安装或简单使用，内置编译可能更直接，但考虑到维护性和清晰性，外置编译是更专业的选择。
大多数开源项目（如 Linux kernel、CMake、LLVM）都推荐使用外置编译方式，这已成为现代 C/C++ 项目的标准实践。
写在最后
道阻且长，行则将至，与君共勉！
感谢您的光临和阅读，让我们一起学习&进步&成长。本文如有错误或不足之处，欢迎私信我，谢谢～
也欢迎您在文末 点赞、分享、推荐，给个3连击，以资鼓励，谢谢～