# cmake macros 改进，及其 600+ 包升级

## issues

https://gitee.com/src-openeuler/cmake/issues/I5OATI ## 使用 cmake 编译安装需要单独定义 DESTDIR

cmake install ./ ## 打包时会导致安装路径不明确，打包文件不完整，所以建议改为： DESTDIR="%{buildroot}" cmake --install ./

https://gitee.com/src-openeuler/cmake/pulls/31 **%cmake_build, %cmake_install 等相关宏的缺失 , 使得从 rpm 生态的其他发行版移植软件包不便。 **

部分 Fedora 中包，如 asdcplib ， SPEC 文件中会使用 %cmake3_build, %cmake3_install 宏定义。

但是在 openEuler 中没有这几个定义，导致用户自行 rpmbuild asdcplib.spec 报错。

https://gitee.com/src-openeuler/cmake/pulls/53

由于相关宏的缺失，很多的确需要 out-of-source building 的包都会在 spec 中通过各种方式手动指定编译目录参数

Closed: 不完全兼容已有 %cmake ，会导致软件包批量构建失败 aom 等软件包批量失败。

https://gitee.com/src-openeuler/cmake/issues/IAND9Y ## cmake 新增支持 %cmake_build 和 %cmake_install 的实施方案

经过多方讨论，提供如下兼容方案 1

## PRs

### 方案 1 ; **Support cmake_build and cmake_install** 【 8 月合入】

| | cmake 包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 ;%**cmake_conf** ;%cmake_build ;%cmake_install | 逐步修改 %cmake 为 ;%cmake_conf ;%cmake_build ;%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行： ;+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"} ;+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义 builddir ， ; 需同步修改 conf/build/install 三阶段 |

【归一化方法】 后续版本在条件允许的时候，将 %cmake 和 %cmake_conf 合并成一个宏

### 方案 2 ; **Update cmake macro** 【讨论中】

| | cmake 包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义 %cmake ， ; 同时定义全局 %__cmake_in_source_build 为 1 ; ; 定义全新 ;%cmake_build ;%cmake_install | 逐步修改 %cmake 为 ;%cmake ;%cmake_build ;%cmake_install ; ; 同时定义 %__cmake_in_source_build=0 | | 后期建议（半年后 , ; 等所有下游包完成改造） | 去掉全局 %__cmake_in_source_build=1 定义 | 移除 %__cmake_in_source_build=0 |

## 决策点 1. 技术方向：方案 1 or 方案 2 ？直接合入 PR80 2. 落地版本：面向未来 25.03 ? 是 3. 回合版本：存量版本 22.03, 24.03 收益 ? 建议：仅回合对 cmake 包的修改，新增宏，以方便用户 rpmbuild 三方包。暂不考虑。 4. 兼容性：同一个 spec, 可以拿到所有版本上去构建？暂不考虑。 5. 分离目录：是最佳实践，是未来方向。但存量软件包迁移是否迫切，收益是否大，优先级是否高？ 6. 在 master 上改 , 批量暴露问题，推动下游包 fix ，缩短切换期， 25.03 分叉点前结束切换 7. release sig 确认 , 出倒排方案 8. oEEP ： fundawang ， fengguang

## 组织修改 600+ 下游包

TODOs ： 1. 确定上述技术路线（二选一） 2. 确定修改清单：在 src-openeuler git 上总共 grep 到 634 个包含 %cmake 的 spec 文件 , 按 SIG 分类，发 email 出来 3. 提供文档与 demo ，目前发现有以下三类包，需要各自提供修改示例 1. %make_build 、 %make_install 2. %ninja_build 、 %ninja_install 3. %__cmake --build 、 %__cmake --install 4. 组织修改 600+ 下游包 spec ，迁移到新的 cmake 宏，落地 25.03 版本 ** 决策点 ** ：如何组织？专人批量修改固定套路的多数包，余下的 push 各个 SIG 组去修改？