在 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组去修改？

 

在 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组去修改？

 

在 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组去修改？

 

在 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组去修改？