[dpdk-dev] [RFCv2 00/40] Building DPDK with meson and ninja

Bruce Richardson bruce.richardson at intel.com
Tue Aug 15 13:31:35 CEST 2017


On Tue, Aug 15, 2017 at 11:56:38AM +0100, Luca Boccassi wrote:
> On Mon, 2017-08-14 at 10:51 +0100, Bruce Richardson wrote:
> > Following on from previous RFC [http://dpdk.org/dev/patchwork/patch/2
> > 5104/]
> > here is a second draft implementation for building DPDK with meson
> > and
> > ninja. While still not building all of DPDK, and needing patch
> > cleanup so
> > that patches don't overwrite previous work, it is more complete in
> > many
> > ways than the previous version and includes:
> > 
> > * dynamic build configuration e.g. building pcap driver only if pcap
> > is
> >   found, only build af_packet if the target is linux, and only
> > building QAT
> >   and openssl crypto drivers if libcrypto is found
> > * support for pmdinfo inside the PMDs(for shared builds) and binaries
> > (for
> >   static builds)
> > * generalized/standardized way of building libs and drivers, though
> > the
> >   drivers code still needs generalization at the driver, rather than
> >   driver-class level.
> > * support for having a pkgconfig file for DPDK on install, and
> > helloworld
> >   and l2fwd can be built using the pkgconfig info (via make, not
> > ninja)
> > * support for library versions
> > * an implementation for FreeBSD as well as Linux
> > * all libraries are included in the build, as well as a number of
> > NIC,
> >   crypto, and mempool drivers
> > * the igb_uio kernel module is build via the kernel Kbuild system as
> > part
> >   of a meson/ninja DPDK build
> > 
> > there is still plenty to do on this, but please review and test it
> > out.
> > I've kept the patches split so that the evolution of the work is a
> > bit
> > clearer than having it all send in a monolithic patch. All feedback
> > welcome. I recommend one uses the latest meson release for this,
> > though the
> > minimum version supported should be v0.4.
> > 
> > I've tested static and dynamic builds with clang and gcc on Fedora
> > 26, and
> > done test builds on FreeBSD 11 with clang too. Build with other
> > compilers
> > and on other OS's may have issues, so YMMV.
> > 
> > To do a basic build, using gcc and with shared libs, in a folder
> > called "gcc-build":
> > 
> > 	user at host:dpdk$ meson gcc-build
> > 	....
> > 	user at host:dpdk$ cd gcc-build
> > 	user at host:gcc-build$ ninja
> > 	user at host:gcc-build$ sudo ninja install
> > 
> > To do a build with clang, using static libs:
> > 
> > 	user at host:dpdk$ CC=clang meson --default_library=static clang-
> > build
> > 	....
> > 	user at host:dpdk$ cd clang-build
> > 	user at host:clang-build$ ninja
> > 	user at host:clang-build$ sudo ninja install
> > 
> > Other options can be adjusted by running "mesonconf" in the build
> > directory, i.e. gcc-build or clang-build in the examples above.
> 
> Hi Bruce,
> 
> This is great, thank you!
> 
> I'll try to give this set a run in the Debian context as soon as I have
> time.
> 
Please do, thanks. Let me know any issues you hit, or further
suggestions for improvement. Please also check the reproducible build
aspects, as I may have let some absolute paths sneek in some places
inadvertently, while getting the more awkward stuff (like pmdinfo)
ported over.

> It's also great to see a pkg-config file!
> 
I'm not sure what others think, but I believe we need to move away from
any requirement for external apps, or even our examples, to have a
particular way of being built. Instead, everything should be done
through the pkg-config, where possible.

> I haven't gone through the diff yet, but do you think it would be
> possible, now or later on, to add the option to install architecture-
> specific headers in a different directory than the arch-independent
> ones?
> 
I'm sure it's possible, it's just a matter of how awkward it would be.
:-)

> This is in the context of multi-arch: on Debian and Ubuntu there's a
> lot of effort to make sure libraries built on different architectures
> are co-installable. Which means either the files must be identical, or
> in arch-specific paths (eg: /usr/include/x86_64-linux-gnu/ and
> /usr/lib/x86_64-linux-gnu/).
> 
> -- 
> Kind regards,
> Luca Boccassi


More information about the dev mailing list