受影响的 600+ spec 清单见附件。
受影响的 SIG 统计: bigdata/sig-info.yaml:1
Private/sig-info.yaml:1
sig-AccLib/sig-info.yaml:1
sig-HPC/sig-info.yaml:1
sig-python-modules/sig-info.yaml:1
sig-recycle/sig-info.yaml:1
sig-RISC-V/sig-info.yaml:1
sig-ROS/sig-info.yaml:1
sig-SDS/sig-info.yaml:1
System-tool/sig-info.yaml:1
xfce/sig-info.yaml:1
sig-bio/sig-info.yaml:2
sig-CloudNative/sig-info.yaml:2
sig-ebpf/sig-info.yaml:2
sig-high-performance-network/sig-info.yaml:2
Networking/sig-info.yaml:3
Runtime/sig-info.yaml:3
sig-embedded/sig-info.yaml:3
DB/sig-info.yaml:4
iSulad/sig-info.yaml:4
sig-compat-winapp/sig-info.yaml:4
sig-Java/sig-info.yaml:4
sig-security-facility/sig-info.yaml:4
Computing/sig-info.yaml:5
GNOME/sig-info.yaml:5
sig-desktop-apps/sig-info.yaml:5
ai/sig-info.yaml:7
sig-OS-Builder/sig-info.yaml:7
Others/sig-info.yaml:9
Programming-language/sig-info.yaml:13
sig-UKUI/sig-info.yaml:16
sig-epol/sig-info.yaml:17
dev-utils/sig-info.yaml:18
Application/sig-info.yaml:21
sig-DDE/sig-info.yaml:27
sig-KIRAN-DESKTOP/sig-info.yaml:28
Desktop/sig-info.yaml:31
Base-service/sig-info.yaml:32
Compiler/sig-info.yaml:36
sig-QT/sig-info.yaml:41
sig-KDE/sig-info.yaml:140
wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang ;
Sent: Wednesday, October 23, 2024 12:35 PM
To: dev@openeuler.org
Cc: liyang (AG) ;
Subject: [Dev] TC 议题: cmake macros 改进总结
# 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 https://gitee.com/src-openeuler/cmake/pulls/81 >; **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 https://gitee.com/src-openeuler/cmake/pulls/80 >; **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 组去修改?
当前进度: 根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。 目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如: https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" wufengguang@huawei.com 写道:
受影响的600+ spec清单见附件。
受影响的SIG统计:
bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang wufengguang@huawei.com Sent: Wednesday, October 23, 2024 12:35 PM To: dev@openeuler.org Cc: liyang (AG) liyang342@huawei.com Subject: [Dev] TC议题:cmake macros改进总结
# 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
https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install |
| 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】
后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2
https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 |
| ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 |
| 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
我草拟了一个cmake macros切换计划,大家看是否OK。 我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。 同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url 5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url 6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支 7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix 8. 重复以上2步
Regards, Fengguang From: Funda Wang fundawang@yeah.net Sent: Friday, October 25, 2024 7:12 PM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com Subject: Re:%cmake引用统计
当前进度: 根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。 目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如: https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 受影响的600+ spec清单见附件。
受影响的SIG统计: bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Sent: Wednesday, October 23, 2024 12:35 PM To: dev@openeuler.orgmailto:dev@openeuler.org Cc: liyang (AG) <liyang342@huawei.commailto:liyang342@huawei.com> Subject: [Dev] TC议题:cmake macros改进总结
# 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 https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2 https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
OpenEuler 批量工作记录 我觉得你还是没有看我先前发过的在线表格,从而过多担忧下游包的情况。你提的这个方案,eulermaker 团队将会牵涉较多精力,且在构建依赖树的过程中,容易浪费不必要的资源。
我这个表是在24.09的发布树里,取得了Buildrequires cmake的所有包,数量比你列出的600+要少。这里边真正采用 in source build 的,只有100多个。这是第一轮要消灭的目标。 剩下的,自行定义了 builddir 的包,只需要去掉这个自定义builddir就可以了。
另外一个值得关注的问题是,25.03 里还开启了 LTO,有一些包可能由于不支持 LTO 而编译失败,这可能与 binutils 有关,在提交 cmake 切换 PR 的时候需要关注。
在 2024-10-26 12:19:39,"wufengguang" wufengguang@huawei.com 写道:
我草拟了一个cmake macros切换计划,大家看是否OK。
我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。
同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1)
2. Fengguang/下游包: 提供600+包含%cmake的包清单
3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误
4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url
5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url
6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支
7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix
8. 重复以上2步
Regards,
Fengguang
From: Funda Wang fundawang@yeah.net Sent: Friday, October 25, 2024 7:12 PM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com Subject: Re:%cmake引用统计
当前进度:
根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。
目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如:https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" wufengguang@huawei.com 写道:
受影响的600+ spec清单见附件。
受影响的SIG统计:
bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang wufengguang@huawei.com Sent: Wednesday, October 23, 2024 12:35 PM To:dev@openeuler.org Cc: liyang (AG) liyang342@huawei.com Subject: [Dev] TC议题:cmake macros改进总结
# 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
https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install |
| 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】
后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2
https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 |
| ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 |
| 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
如果只有100多个spec会报错,那当然更好。 写几个脚本不会费多大的事,关键是我们自此建立了一套批量重构和演进的流程。后续全仓使能LTO,也可以照此方法推进。
From: Funda Wang fundawang@yeah.net Sent: Monday, October 28, 2024 11:33 AM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com; yangchaohao yangchaohao@huawei.com Subject: Re:[Dev] Re: %cmake引用统计
OpenEuler 批量工作记录https://docs.qq.com/sheet/DWkxLU1JiUUNaVU5a?tab=kr08vj 我觉得你还是没有看我先前发过的在线表格,从而过多担忧下游包的情况。你提的这个方案,eulermaker 团队将会牵涉较多精力,且在构建依赖树的过程中,容易浪费不必要的资源。
我这个表是在24.09的发布树里,取得了Buildrequires cmake的所有包,数量比你列出的600+要少。这里边真正采用 in source build 的,只有100多个。这是第一轮要消灭的目标。 剩下的,自行定义了 builddir 的包,只需要去掉这个自定义builddir就可以了。
另外一个值得关注的问题是,25.03 里还开启了 LTO,有一些包可能由于不支持 LTO 而编译失败,这可能与 binutils 有关,在提交 cmake 切换 PR 的时候需要关注。
在 2024-10-26 12:19:39,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 我草拟了一个cmake macros切换计划,大家看是否OK。 我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。 同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url 5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url 6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支 7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix 8. 重复以上2步
Regards, Fengguang From: Funda Wang <fundawang@yeah.netmailto:fundawang@yeah.net> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Cc: dev@openeuler.orgmailto:dev@openeuler.org; tc <tc@openeuler.orgmailto:tc@openeuler.org>; wfg@mail.ustc.edu.cnmailto:wfg@mail.ustc.edu.cn; duanpengjie <duanpengjie@huawei.commailto:duanpengjie@huawei.com> Subject: Re:%cmake引用统计
当前进度: 根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。 目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如: https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 受影响的600+ spec清单见附件。
受影响的SIG统计: bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Sent: Wednesday, October 23, 2024 12:35 PM To: dev@openeuler.orgmailto:dev@openeuler.org Cc: liyang (AG) <liyang342@huawei.commailto:liyang342@huawei.com> Subject: [Dev] TC议题:cmake macros改进总结
# 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 https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2 https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
只有100多个报错是不可能的,由于%cmake的定义发生变化,所有这些包在进行到 make 这一步的时候都会报错,因为当前文件夹找不到 Makefile。这里边还牵涉一些自行编写了 build.sh 脚本的自研软件,要说服工程师修改难度很大。
我不倾向于建单独的试验仓,原因是spec的这次修改,并不会导致二进制包产生变化。对这个试验仓进行定时重建是非必要的,不但会浪费大量机器时间和资源,这个操作在maintainer的角度还很难复现。
在 2024-10-29 10:06:33,"wufengguang" wufengguang@huawei.com 写道:
如果只有100多个spec会报错,那当然更好。
写几个脚本不会费多大的事,关键是我们自此建立了一套批量重构和演进的流程。后续全仓使能LTO,也可以照此方法推进。
From: Funda Wang fundawang@yeah.net Sent: Monday, October 28, 2024 11:33 AM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com; yangchaohao yangchaohao@huawei.com Subject: Re:[Dev] Re: %cmake引用统计
OpenEuler 批量工作记录
我觉得你还是没有看我先前发过的在线表格,从而过多担忧下游包的情况。你提的这个方案,eulermaker 团队将会牵涉较多精力,且在构建依赖树的过程中,容易浪费不必要的资源。
我这个表是在24.09的发布树里,取得了Buildrequires cmake的所有包,数量比你列出的600+要少。这里边真正采用 in source build 的,只有100多个。这是第一轮要消灭的目标。
剩下的,自行定义了 builddir 的包,只需要去掉这个自定义builddir就可以了。
另外一个值得关注的问题是,25.03 里还开启了 LTO,有一些包可能由于不支持 LTO 而编译失败,这可能与 binutils 有关,在提交 cmake 切换 PR 的时候需要关注。
在 2024-10-26 12:19:39,"wufengguang" wufengguang@huawei.com 写道:
我草拟了一个cmake macros切换计划,大家看是否OK。
我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。
同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1)
2. Fengguang/下游包: 提供600+包含%cmake的包清单
3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误
4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url
5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url
6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支
7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix
8. 重复以上2步
Regards,
Fengguang
From: Funda Wang fundawang@yeah.net Sent: Friday, October 25, 2024 7:12 PM To: wufengguang wufengguang@huawei.com Cc:dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com Subject: Re:%cmake引用统计
当前进度:
根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。
目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如:https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" wufengguang@huawei.com 写道:
受影响的600+ spec清单见附件。
受影响的SIG统计:
bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang wufengguang@huawei.com Sent: Wednesday, October 23, 2024 12:35 PM To:dev@openeuler.org Cc: liyang (AG) liyang342@huawei.com Subject: [Dev] TC议题:cmake macros改进总结
# 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
https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install |
| 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】
后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2
https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 |
| ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 |
| 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
不是试验仓,是独立的构建工程,用于暴露和跟踪构建问题,提供调试log。 350+包的构建工程,对我们资源压力不算大。这一点你可以放宽心,反正有压力也是在我们这边。
From: Funda Wang fundawang@yeah.net Sent: Tuesday, October 29, 2024 10:54 AM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com; yangchaohao yangchaohao@huawei.com Subject: Re:[Dev] Re: %cmake引用统计
只有100多个报错是不可能的,由于%cmake的定义发生变化,所有这些包在进行到 make 这一步的时候都会报错,因为当前文件夹找不到 Makefile。这里边还牵涉一些自行编写了 build.sh 脚本的自研软件,要说服工程师修改难度很大。
我不倾向于建单独的试验仓,原因是spec的这次修改,并不会导致二进制包产生变化。对这个试验仓进行定时重建是非必要的,不但会浪费大量机器时间和资源,这个操作在maintainer的角度还很难复现。
在 2024-10-29 10:06:33,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 如果只有100多个spec会报错,那当然更好。 写几个脚本不会费多大的事,关键是我们自此建立了一套批量重构和演进的流程。后续全仓使能LTO,也可以照此方法推进。
From: Funda Wang <fundawang@yeah.netmailto:fundawang@yeah.net> Sent: Monday, October 28, 2024 11:33 AM To: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Cc: dev@openeuler.orgmailto:dev@openeuler.org; tc <tc@openeuler.orgmailto:tc@openeuler.org>; wfg@mail.ustc.edu.cnmailto:wfg@mail.ustc.edu.cn; duanpengjie <duanpengjie@huawei.commailto:duanpengjie@huawei.com>; yangchaohao <yangchaohao@huawei.commailto:yangchaohao@huawei.com> Subject: Re:[Dev] Re: %cmake引用统计
OpenEuler 批量工作记录https://docs.qq.com/sheet/DWkxLU1JiUUNaVU5a?tab=kr08vj 我觉得你还是没有看我先前发过的在线表格,从而过多担忧下游包的情况。你提的这个方案,eulermaker 团队将会牵涉较多精力,且在构建依赖树的过程中,容易浪费不必要的资源。
我这个表是在24.09的发布树里,取得了Buildrequires cmake的所有包,数量比你列出的600+要少。这里边真正采用 in source build 的,只有100多个。这是第一轮要消灭的目标。 剩下的,自行定义了 builddir 的包,只需要去掉这个自定义builddir就可以了。
另外一个值得关注的问题是,25.03 里还开启了 LTO,有一些包可能由于不支持 LTO 而编译失败,这可能与 binutils 有关,在提交 cmake 切换 PR 的时候需要关注。
在 2024-10-26 12:19:39,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 我草拟了一个cmake macros切换计划,大家看是否OK。 我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。 同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url 5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url 6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支 7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix 8. 重复以上2步
Regards, Fengguang From: Funda Wang <fundawang@yeah.netmailto:fundawang@yeah.net> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Cc: dev@openeuler.orgmailto:dev@openeuler.org; tc <tc@openeuler.orgmailto:tc@openeuler.org>; wfg@mail.ustc.edu.cnmailto:wfg@mail.ustc.edu.cn; duanpengjie <duanpengjie@huawei.commailto:duanpengjie@huawei.com> Subject: Re:%cmake引用统计
当前进度: 根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。 目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如: https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 受影响的600+ spec清单见附件。
受影响的SIG统计: bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Sent: Wednesday, October 23, 2024 12:35 PM To: dev@openeuler.orgmailto:dev@openeuler.org Cc: liyang (AG) <liyang342@huawei.commailto:liyang342@huawei.com> Subject: [Dev] TC议题:cmake macros改进总结
# 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 https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2 https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
创建 meta issue 我是同意的。然而gitee的接口是否允许创建子 issue,这个可能要咨询一下。就是将子issue发配给各仓库之后,把这些子issue设置为 meta issue 的子项,便于跟踪进度。
在 2024-10-26 12:19:39,"wufengguang" wufengguang@huawei.com 写道:
我草拟了一个cmake macros切换计划,大家看是否OK。
我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。
同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1)
2. Fengguang/下游包: 提供600+包含%cmake的包清单
3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误
4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url
5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url
6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支
7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix
8. 重复以上2步
Regards,
Fengguang
From: Funda Wang fundawang@yeah.net Sent: Friday, October 25, 2024 7:12 PM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com Subject: Re:%cmake引用统计
当前进度:
根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。
目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如:https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" wufengguang@huawei.com 写道:
受影响的600+ spec清单见附件。
受影响的SIG统计:
bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang wufengguang@huawei.com Sent: Wednesday, October 23, 2024 12:35 PM To:dev@openeuler.org Cc: liyang (AG) liyang342@huawei.com Subject: [Dev] TC议题:cmake macros改进总结
# 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
https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install |
| 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】
后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2
https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 |
| ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 |
| 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
普通issue就可以了,EulerMaker团队不会去跟踪这些issue,仅仅是把它当做提醒开发者的一个途径(还有一个途径是email)。 EulerMaker团队会定期重新构建该工程。还继续有问题的包,继续发email提醒。已经fix的包,就不再做任何事。
From: Funda Wang fundawang@yeah.net Sent: Monday, October 28, 2024 3:27 PM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com; yangchaohao yangchaohao@huawei.com Subject: Re:[Dev] Re: %cmake引用统计
创建 meta issue 我是同意的。然而gitee的接口是否允许创建子 issue,这个可能要咨询一下。就是将子issue发配给各仓库之后,把这些子issue设置为 meta issue 的子项,便于跟踪进度。
在 2024-10-26 12:19:39,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 我草拟了一个cmake macros切换计划,大家看是否OK。 我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。 同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1) 2. Fengguang/下游包: 提供600+包含%cmake的包清单 3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误 4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url 5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url 6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支 7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix 8. 重复以上2步
Regards, Fengguang From: Funda Wang <fundawang@yeah.netmailto:fundawang@yeah.net> Sent: Friday, October 25, 2024 7:12 PM To: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Cc: dev@openeuler.orgmailto:dev@openeuler.org; tc <tc@openeuler.orgmailto:tc@openeuler.org>; wfg@mail.ustc.edu.cnmailto:wfg@mail.ustc.edu.cn; duanpengjie <duanpengjie@huawei.commailto:duanpengjie@huawei.com> Subject: Re:%cmake引用统计
当前进度: 根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。 目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如: https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" <wufengguang@huawei.commailto:wufengguang@huawei.com> 写道: 受影响的600+ spec清单见附件。
受影响的SIG统计: bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang <wufengguang@huawei.commailto:wufengguang@huawei.com> Sent: Wednesday, October 23, 2024 12:35 PM To: dev@openeuler.orgmailto:dev@openeuler.org Cc: liyang (AG) <liyang342@huawei.commailto:liyang342@huawei.com> Subject: [Dev] TC议题:cmake macros改进总结
# 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 https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install | | 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】 后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2 https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 | | ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 | | 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?
cmake 宏更新项目,自2024年11月4日至发稿时止,经我手创建的 PR 共 175 个,其中 105 个已合并,剩余 60 个待 maintainer 确认合并。经过多轮重构,构建失败记录里涉及最多的 SIG 是 Desktop、sig-UKUI,sig-KIRAN-DESKTOP、sig-QT。这些 SIG 对 PR 的响应速度慢,是本项目进展缓慢的主要原因。
%cmake 宏的变化即将于2503创新版本生效,请各 maintainer 引起关注。响应速度慢的 SIG 组届时将不得不自行处理宏变化导致的构建失败。
在 2024-10-26 12:19:39,"wufengguang" wufengguang@huawei.com 写道:
我草拟了一个cmake macros切换计划,大家看是否OK。
我仍然建议定义全局%__cmake_in_source_build为1,以保证master分支平滑切换,下游包的fix流程也最简单。
同时,通过步骤3-8推动问题暴露和下游包fix。
1. FundaWang/cmake包:在master上合入cmake macros(兼容版本,即PR 80 + 定义全局%__cmake_in_source_build为1)
2. Fengguang/下游包: 提供600+包含%cmake的包清单
3. EulerMaker团队:创建1个工程,总计600+包url,src-openeuler/$pkg/,定义全局%__cmake_in_source_build为0,触发错误
4. FundaWang: fix几个典型情况,提交PR作为demo url;写cmake宏切换文档url
5. EulerMaker团队:写脚本,批量给600+仓提issue,提供cmake宏切换文档url及log url
6. 600+维护者:fork个人仓,fix,提PR到src-openeuler/$pkg/,合入master分支
7. EulerMaker团队:再次批量构建,对未fix的,写脚本,通过sig-info.yaml查发email催促fix
8. 重复以上2步
Regards,
Fengguang
From: Funda Wang fundawang@yeah.net Sent: Friday, October 25, 2024 7:12 PM To: wufengguang wufengguang@huawei.com Cc: dev@openeuler.org; tc tc@openeuler.org; wfg@mail.ustc.edu.cn; duanpengjie duanpengjie@huawei.com Subject: Re:%cmake引用统计
当前进度:
根据TC决议,oEEP 已创建: https://gitee.com/openeuler/TC/pulls/110 请大家提出修改意见。
目前已有下游工程师反馈,希望用同一个SPEC在前置版本中构建,如:https://gitee.com/src-openeuler/openvino/pulls/1
在 2024-10-23 17:02:32,"wufengguang" wufengguang@huawei.com 写道:
受影响的600+ spec清单见附件。
受影响的SIG统计:
bigdata/sig-info.yaml:1 Private/sig-info.yaml:1 sig-AccLib/sig-info.yaml:1 sig-HPC/sig-info.yaml:1 sig-python-modules/sig-info.yaml:1 sig-recycle/sig-info.yaml:1 sig-RISC-V/sig-info.yaml:1 sig-ROS/sig-info.yaml:1 sig-SDS/sig-info.yaml:1 System-tool/sig-info.yaml:1 xfce/sig-info.yaml:1 sig-bio/sig-info.yaml:2 sig-CloudNative/sig-info.yaml:2 sig-ebpf/sig-info.yaml:2 sig-high-performance-network/sig-info.yaml:2 Networking/sig-info.yaml:3 Runtime/sig-info.yaml:3 sig-embedded/sig-info.yaml:3 DB/sig-info.yaml:4 iSulad/sig-info.yaml:4 sig-compat-winapp/sig-info.yaml:4 sig-Java/sig-info.yaml:4 sig-security-facility/sig-info.yaml:4 Computing/sig-info.yaml:5 GNOME/sig-info.yaml:5 sig-desktop-apps/sig-info.yaml:5 ai/sig-info.yaml:7 sig-OS-Builder/sig-info.yaml:7 Others/sig-info.yaml:9 Programming-language/sig-info.yaml:13 sig-UKUI/sig-info.yaml:16 sig-epol/sig-info.yaml:17 dev-utils/sig-info.yaml:18 Application/sig-info.yaml:21 sig-DDE/sig-info.yaml:27 sig-KIRAN-DESKTOP/sig-info.yaml:28 Desktop/sig-info.yaml:31 Base-service/sig-info.yaml:32 Compiler/sig-info.yaml:36 sig-QT/sig-info.yaml:41 sig-KDE/sig-info.yaml:140 wfg /c/openeuler/community/sig% grep -c -f cmake-pkgs */sig-info.yaml | sort -n -k2 -t:
From: wufengguang wufengguang@huawei.com Sent: Wednesday, October 23, 2024 12:35 PM To:dev@openeuler.org Cc: liyang (AG) liyang342@huawei.com Subject: [Dev] TC议题:cmake macros改进总结
# 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
https://gitee.com/src-openeuler/cmake/pulls/81 **Support cmake_build and cmake_install** 【8月合入】
| | cmake包 | 各下游包 |
| --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 修改 | 定义全新 <br>%**cmake_conf**<br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake_conf<br>%cmake_build<br>%cmake_install |
| 注解 | %cmake_conf 是在 %cmake 的基础上增加如下两行:<br>+ %{!?__cmake_in_source_build:-S "%{_vpath_srcdir}"}<br>+ %{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} | 一旦定义builddir,<br>需同步修改conf/build/install三阶段 |
【归一化方法】
后续版本在条件允许的时候,将 %cmake 和 %cmake_conf 合并成一个宏
### 方案2
https://gitee.com/src-openeuler/cmake/pulls/80 **Update cmake macro** 【讨论中】
| | cmake包 | 各下游包 |
| ------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 修改 | 重定义%cmake,<br>同时定义全局%__cmake_in_source_build为1<br><br>定义全新 <br>%cmake_build<br>%cmake_install | 逐步修改 %cmake 为<br>%cmake<br>%cmake_build<br>%cmake_install<br><br>同时定义%__cmake_in_source_build=0 |
| 后期建议(半年后, <br>等所有下游包完成改造) | 去掉全局%__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组去修改?