目录

聪明人的学习和工作的模式

制作RPM包，分为几步：

那么需要在事先准备一些信息

聪明人的学习和工作的模式

我见过一些聪明人的学习和工作模式。

我们这一代人，而临着每天都要学习新知识的困境。聪明的人，在学习之前，会审视自己的需求，然后理解上下文场景，然后，最重要的一步，是思考如果是自己去设计正要学习的工具，将如何来设计与实现。

制作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文件，与手工编出来的并不一致。

后面我们重点说这个问题。

Linux的RPM机制的问题

一个聪明的人，需要去研究当前的工具和场景的问题。这不是为了挑毛病。

而是思考，当前这种问题的根源是什么。

你要知道，设计的人，也都是聪明人。

但是，千成不要停止在这里。聪明人，是站在其自身角度，未必对他人是友好的。

先说一下结论

对于dpdk这个包来讲，meson后面，什么参数都不加，反而比redhad提供的更好

这一大堆：

%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 + ninja

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}