[dpdk-dev] Meson Minimum Version

Bruce Richardson bruce.richardson at intel.com
Fri Sep 25 10:41:22 CEST 2020


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.

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


More information about the dev mailing list