[dpdk-dev] Meson Minimum Version

Morten Brørup mb at smartsharesystems.com
Fri Sep 25 10:58:36 CEST 2020


> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, September 25, 2020 10:41 AM
> To: Morten Brørup
> 
> On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> Richardson
> > > Sent: Thursday, September 24, 2020 5:43 PM
> > >
> > > On Thu, Sep 24, 2020 at 03:32:41PM +0000, John Alexander wrote:
> > > >    Hi,
> > > >    Regarding the subproject local patch support, yes, it's only
> > > supported
> > > >    since Meson 0.55:
> > > >    https://mesonbuild.com/Wrap-dependency-system-manual.html We
> pip
> > > >    installed 0.55 Meson.
> > > >    I have a number of subsequent patches that depend on this
> > > particular
> > > >    pthreads library to advance the Windows DPDK support. Locally,
> we
> > > have
> > > >    testpmd (minus mmap'd external memory currently) running
> against
> > > the
> > > >    Intel i40e PMD (XL710 4x10Gbps SPF+ NIC) on Windows on our
> local
> > > DPDK
> > > >    fork (based off 20.08-rc2 using Microsoft's latest NetUIO
> driver).
> > > We
> > > >    have 47 of the 51 RTE libraries building and have had l2fwd,
> > > l3fwd,
> > > >    ipv4_multicast and almost all of the regression tests
> > > compiling+linking
> > > >    too. I'd like to push as much of the Windows EAL work we've
> done
> > > >    upstream if I can (after a bit of tidying up :).
> > > >    I've also coded up a meson build patch for the Jansson JSON
> parser
> > > used
> > > >    by the RTE metrics library (the config.h generation was quite
> > > fiddly!)
> > > >    That's ready to go. We get nice meson syntax as follows to
> specify
> > > a
> > > >    fallback if the library isn't installed locally:
> > > >    jansson = dependency('jansson', required: false, fallback :
> > > ['jansson',
> > > >    'jansson_static_dep'])
> > > >    I believe the meson command line enables disabling fallbacks
> if
> > > people
> > > >    would prefer not to use them (--wrap-mode=nofallback).
> > > >    Kind regards,
> > > >    John.
> > >
> > > Hi again, John,
> > >
> > > thanks for the full reply - the work you have sounds really good,
> and
> > > the
> > > possibilities using the wrap support are definitely of interest.
> > > [Though
> > > since jansson is only used for the legacy parts of the telemetry
> > > library
> > > I'm not sure we want to wrap it just for that - the later telemetry
> > > work
> > > from this year doesn't depend on jansson. Then again, the
> > > vm_power_manager
> > > example also uses it too...]. It's probably something that would be
> > > especially useful for software dependencies that aren't normally
> > > packaged.
> > >
> > > I've added techboard on CC to previous reply, so hopefully we'll
> get
> > > some
> > > thoughts from others.
> > >
> >
> > A buggy C compiler might generate buggy code, and the compiler
> induced bugs may not be caught during development (but hopefully during
> testing). I have seen this happen, and I still consider it a realistic
> scenario. This is the strongest argument for using a trusted version of
> the C compiler, which is supported by the popular GNU/Linux
> distributors (Red Hat etc.), or sufficiently vetted to be included in
> the Crosstool-NG project, or similar.
> >
> > Meson is a relatively simple tool, so I personally wouldn't mind
> overwriting the distro-supported version on our build systems with a
> new version. (I haven't worked much with Meson, but assume that the new
> version of Meson is backwards compatible with its earlier versions.)
> >
> > In short, my primary concern is: What could realistically go wrong if
> the required version of Meson is buggy?
> >
> > Bruce, you have worked for quite a while with Meson/Ninja by now, so
> perhaps you can assess this risk based on your experience.
> >
> I'd say the risk in this case is small, especially since I see that
> 0.56 of
> meson is well under way for development and may well be released before
> DPDK 20.11. Generally backwards compatibilty of meson is excellent as
> they
> have comprehensive test suite for all features.
> 

Thank you for the qualified risk assessment, Bruce.

> Rather than any bugginess, my concern was purely requiring people to
> update
> meson using "pip3", but I suppose that's not really a big deal, and
> when
> using pip update it defaults to just updating the copy for the local
> user,
> not system-wide.
> 
> Updating to a later meson will give us access to a few other nice
> features
> we can use also (from earlier releases than 0.55), such as support for
> "break" and "continue" keywords in loops, which can simplify out lib or
> driver building code, perhaps, or the "console" parameter for custom
> targets which should improve the output visibility when builing our
> docs.
> 
> /Bruce

I vote for requiring the later Meson version.

-Morten



More information about the dev mailing list