Re: [Dev] Re: %cmake引用统计 - Tc

29 Oct 2024


      不是 试验仓，是独立的构建工程，用于暴露和跟踪构建问题，提供调试 log 。   
 350&#43; 包的构建工程，对我们资源压力不算大。这一点你可以放宽心，反正有压力也是在我们这边。
From:  Funda Wang ;
Sent: Tuesday, October 29, 2024 10:54 AM
To: wufengguang ;
Cc: dev@openeuler.org; tc ;; wfg@mail.ustc.edu.cn; duanpengjie ;; yangchaohao ;
Subject: Re:[Dev] Re: %cmake 引用统计
只有 100 多个报错是不可能的，由于 %cmake 的定义发生变化，所有这些包在进行到 
 make  这一步的时候都会报错，因为当前文件夹找不到  Makefile 。这里边还牵涉一些自行编写了 
 build.sh  脚本的自研软件，要说服工程师修改难度很大。
我不倾向于建单独的试验仓，原因是 spec 的这次修改，并不会导致二进制包产生变化。对这个试验仓进行定时重建是非必要的，不但会浪费大量机器时间和资源，这个操作在 maintainer 的角度还很难复现。
在  2024-10-29 10:06:33 ， &quot;wufengguang&quot;
 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&#43; 要少。这里边真正采用 
 in source build  的，只有 100 多个。这是第一轮要消灭的目标。
剩下的，自行定义了  builddir
 的包，只需要去掉这个自定义 builddir 就可以了。
另外一个值得关注的问题是， 25.03
 里还开启了  LTO ，有一些包可能由于不支持 
 LTO  而编译失败，这可能与  binutils
 有关，在提交  cmake
 切换  PR
 的时候需要关注。
在  2024-10-26 12:19:39 ， &quot;wufengguang&quot;
 wufengguang@huawei.com >;  写道：
我草拟了一个 cmake macros 切换计划，大家看是否 OK 。   
 我仍然建议定义全局 %__cmake_in_source_build 为 1 ，以保证 master 分支平滑切换，下游包的 fix 流程也最简单。   
 同时，通过步骤 3-8 推动问题暴露和下游包 fix 。
1. FundaWang/cmake 包：在 master 上合入 cmake
 macros （兼容版本，即 PR 80 &#43; 定义全局 %__cmake_in_source_build 为 1)    
 2. Fengguang/ 下游包 :
 提供 600&#43; 包含 %cmake 的包清单   
 3. EulerMaker 团队：创建 1 个工程，总计 600&#43; 包 url ， src-openeuler/$pkg/ ，定义全局 %__cmake_in_source_build 为 0, 触发错误   
 4. FundaWang: fix 几个典型情况，提交 PR 作为 demo
 url ；写 cmake 宏切换文档 url    
 5. EulerMaker 团队：写脚本，批量给 600&#43; 仓提 issue ，提供 cmake 宏切换文档 url 及 log
 url    
 6. 600&#43; 维护者： 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 ， &quot;wufengguang&quot;
 wufengguang@huawei.com >;  写道：
受影响的 600&#43; 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&#43; 包升级
## issues
https://gitee.com/src-openeuler/cmake/issues/I5OATI  
 ##  使用 cmake 编译安装需要单独定义 DESTDIR
cmake install ./ ##
 打包时会导致安装路径不明确，打包文件不完整，所以建议改为：   
 DESTDIR=&quot;%{buildroot}&quot; 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
 的基础上增加如下两行：  ;&#43; %{!?__cmake_in_source_build:-S &quot;%{_vpath_srcdir}&quot;} ;&#43; %{!?__cmake_in_source_build:-B &quot;%{__cmake_builddir}&quot;}
 |  一旦定义 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&#43; 下游包
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&#43; 下游包 spec ，迁移到新的 cmake 宏，落地 25.03 版本   
   ** 决策点 ** ：如何组织？专人批量修改固定套路的多数包，余下的 push 各个 SIG 组去修改？