目录
聪明人的学习和工作的模式
制作RPM包,分为几步:
那么需要在事先准备一些信息
我见过一些聪明人的学习和工作模式。
我们这一代人,而临着每天都要学习新知识的困境。聪明的人,在学习之前,会审视自己的需求,然后理解上下文场景,然后,最重要的一步,是思考如果是自己去设计正要学习的工具,将如何来设计与实现。
准备,编译,install。
分别对应于spec脚本的
%prep, %build, %install
外部的环境,包括操作系统 ,编译环境,和配置工具。
这次我的需求是定制dpdk-20.11版本的rpm包。
1。 待编译的自定义的DPDK的源码;
2. 能够手工完成编译和安装。
2。 去网上寻找其它公司,例如redhat公司的spec库:Overview - rpms/dpdk - CentOS Git server
下载之后,找到相关的分支,相关的tag,然后下载下关的代码,完成制包的工作。
这些都没有什么困难。只是花时间。
先研究清楚,如何验证。
例如,我自己买了正版的beyond compare,将编译后的.so进行比较。
在将原始dpdk rpmbuild环境中的代码,换为自定义的dpdk之后,得到的编译.so文件,与手工编出来的并不一致。
后面我们重点说这个问题。
一个聪明的人,需要去研究当前的工具和场景的问题。这不是为了挑毛病。
而是思考,当前这种问题的根源是什么。
你要知道,设计的人,也都是聪明人。
但是,千成不要停止在这里。聪明人,是站在其自身角度,未必对他人是友好的。
先说一下结论
这一大堆:
%define meson \
export CFLAGS="${CFLAGS:-%__global_cflags}" \
export CXXFLAGS="${CXXFLAGS:-%__global_cxxflags}" \
export FFLAGS="${FFLAGS:-%__global_fflags}" \
export FCFLAGS="${FCFLAGS:-%__global_fcflags}" \
export LDFLAGS="${LDFLAGS:-%__global_ldflags}" \
%{__meson} \\\
--buildtype=plain \\\
--prefix=%{_prefix} \\\
--libdir=%{_libdir} \\\
--libexecdir=%{_libexecdir} \\\
--bindir=%{_bindir} \\\
--sbindir=%{_sbindir} \\\
--includedir=%{_includedir} \\\
--datadir=%{_datadir} \\\
--mandir=%{_mandir} \\\
--infodir=%{_infodir} \\\
--localedir=%{_datadir}/locale \\\
--sysconfdir=%{_sysconfdir} \\\
--localstatedir=%{_localstatedir} \\\
--sharedstatedir=%{_sharedstatedir} \\\
--wrap-mode=%{__meson_wrap_mode} \\\
--auto-features=%{__meson_auto_features} \\\
%{_vpath_srcdir} %{_vpath_builddir} \\\
%{nil}
不如
%define meson \
meson x86_64-redhat-linux-gnu
注意%define,只是定义了一个宏。
spec,大部分代码,是这些准备工作。反而prep,build,install,一般代码很少。
所以,上面的真实的代码是:
meson meson x86_64-redhat-linux-gnu
或者你自己想要的目录:
meson mybuild
这是因为linux系统的一直不好的习惯。
1。 承认主动对象
2。 给以主动对象一定的自主权
3。 能够海纳百川地,理解各种主动对象的对个可配置参数。
但是linux,总是试图大而不当的统一。
这里最关键是这几句
%define meson \
export CFLAGS="${CFLAGS:-%__global_cflags}" \
export CXXFLAGS="${CXXFLAGS:-%__global_cxxflags}" \
export FFLAGS="${FFLAGS:-%__global_fflags}" \
export FCFLAGS="${FCFLAGS:-%__global_fcflags}" \
export LDFLAGS="${LDFLAGS:-%__global_ldflags}" \
这些变量,都在这里定义:
/usr/lib/rpm/rpmrc
和macro文件中。
特别地, redhat自己建立了自己的。
这些就不是良好的设计。
原始的目标是,一台机器上,所有的RPM的GCC编译参数都是相同的。
那么,我想问,这个需求的合理性在哪里?
是不是我一个rpm包,没有用统一的编译参数就不能运行呢?这显然不成立。
例如,我想调试dpdk,难道 说,其它的包也编译为debug版吗?
而且,事实上,这里面存在bug: rpm 的 RPM_OPT_FLAGS 参数,被编译和链接,同时共用,这里导致了极为混乱的复杂。
结果是什么呢?
meson之所以要被发明,就是要绕过这令人恼火的管得过宽的OS和rpmbuild,
然是,显然,redhat的工程师不么想。
他们显然是meson想消灭的存在,
结果,经过redhat的工程师的不懈努力,又重新将缰绳套在了meson上:
本来应该是这样:
meson mybuild
redhat一定要重新改回这样:
%define meson \
export CFLAGS="${CFLAGS:-%__global_cflags}" \
export CXXFLAGS="${CXXFLAGS:-%__global_cxxflags}" \
export FFLAGS="${FFLAGS:-%__global_fflags}" \
export FCFLAGS="${FCFLAGS:-%__global_fcflags}" \
export LDFLAGS="${LDFLAGS:-%__global_ldflags}" \
%{__meson} \\\
--buildtype=plain \\\
--prefix=%{_prefix} \\\
--libdir=%{_libdir} \\\
--libexecdir=%{_libexecdir} \\\
--bindir=%{_bindir} \\\
--sbindir=%{_sbindir} \\\
--includedir=%{_includedir} \\\
--datadir=%{_datadir} \\\
--mandir=%{_mandir} \\\
--infodir=%{_infodir} \\\
--localedir=%{_datadir}/locale \\\
--sysconfdir=%{_sysconfdir} \\\
--localstatedir=%{_localstatedir} \\\
--sharedstatedir=%{_sharedstatedir} \\\
--wrap-mode=%{__meson_wrap_mode} \\\
--auto-features=%{__meson_auto_features} \\\
%{_vpath_srcdir} %{_vpath_builddir} \\\
%{nil}