按原定进度，cmake 有关宏已于近日在 master 分支上切换完成，并将带入 25.03 创新版本。当前默认的设置为 out-of-source build。详见 oEEP：openEuler oEEP | openEuler社区 由于 25.03 创新版本中进行的操作系统构建基座变化较多，请各 maintainer 密切关注软件包是否构建安装成功，尽早修复。 在 2024-12-20 17:00:59，"Funda Wang" <fundawang@yeah.net> 写道： 近日，凡是 cmake 宏更新后会导致构建失败的包，已经批量在包的制品仓 src-openEuler 中创建了 issue，希望各 maintainer 引起关注。 其中部分包已经提交了有关PR，但尚未合入，请有关 SIG 加紧处理，以在 25.03 分叉之前解决并顺利过渡。下附表： | 仓库 | 包名 | SIG | | everything | chatglm.cpp | A-Tune | | everything | gl2ps | bigdata | | everything | Bear | Compiler | | everything | ccache | Compiler | | everything | automoc | dev-utils | | everything | glm | dev-utils | | everything | wpebackend-fdo | dev-utils | | everything | editorconfig | GNOME | | everything | iSulad | iSulad | | everything | lcr | iSulad | | everything | libssh | Networking | | everything | qhull | Others | | everything | cmocka | Programming-language | | everything | gtest | Programming-language | | everything | jsoncpp | Programming-language | | everything | socket_wrapper | Programming-language | | everything | freeglut | Runtime | | everything | bcc | sig-ebpf | | everything | bpftrace | sig-ebpf | | everything | eigen3 | sig-epol | | everything | ft_surface | sig-FangTian | | everything | dwarves | sig-high-performance-network | | everything | rdma-core | sig-high-performance-network | | everything | pybind11 | sig-python-modules | | everything | libomp | sig-ROS | | everything | nss-pem | sig-security-facility | | everything | pam_wrapper | sig-security-facility | | EPOL | blur-effect | desktop | | EPOL | cmark | GNOME | | EPOL | cryfs | sig-DDE | | EPOL | dareader | sig-DDE | | EPOL | featherpad | sig-desktop-apps | | EPOL | gammaray | sig-desktop-apps | | EPOL | libmetal | sig-embedded | | EPOL | Catch2 | sig-ROS | | EPOL | fcl | sig-ROS | | EPOL | flann | sig-ROS | | EPOL | libccd | sig-ROS | | EPOL | libomp | sig-ROS | | EPOL | octomap | sig-ROS | | EPOL | pcl | sig-ROS | | EPOL | range-v3 | sig-ROS | | EPOL | spdlog | sig-ROS | | EPOL | attica | sig-UKUI | | EPOL | fcitx5 | sig-UKUI | | EPOL | grantlee | sig-UKUI | | EPOL | grantlee-qt5 | sig-UKUI | | EPOL | polkit-qt-1 | sig-UKUI | | EPOL | shared-desktop-ontologies | sig-UKUI | | EPOL | ukui-kwin-effects | sig-UKUI | | EPOL | ukui-menu | sig-UKUI | | EPOL | ukui-menu-extensions | sig-UKUI | | EPOL | ukui-notification | sig-UKUI | | EPOL | ukui-panel | sig-UKUI | | EPOL | ukui-search | sig-UKUI | | EPOL | ukui-session-manager | sig-UKUI | | EPOL | ukui-window-switch | sig-UKUI | | EPOL | xcb-imdkit | sig-UKUI | 在 2024-11-28 18:45:52，"Funda Wang" <fundawang@yeah.net> 写道： 目前仍是 Desktop、sig-QT、sig-UKUI 响应速度慢。其它SIG受%cmake宏定义变化切换影响的包就少，但也有怠于跟踪的情况。 %cmake 宏的变化即将于2503创新版本生效，请各 maintainer 引起关注。响应速度慢的 SIG 组届时将不得不自行处理宏变化导致的构建失败。 另外，部分软件包的构建失败与 cmake 宏切换无关，请各 maintainer 关注 eulermaker 上的全仓构建进度，及时处理。 在 2024-11-18 22:04:21，"Funda Wang" <fundawang@yeah.net> 写道： 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组去修改？