DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: John Alexander <John.Alexander@datapath.co.uk>,
	dev@dpdk.org, techboard@dpdk.org
Subject: Re: [dpdk-dev] Meson Minimum Version
Date: Fri, 25 Sep 2020 09:41:22 +0100	[thread overview]
Message-ID: <20200925084122.GA923@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk>

On Fri, Sep 25, 2020 at 09:31:53AM +0200, Morten Brørup wrote:
> > From: dev [mailto:dev-bounces@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

  reply	other threads:[~2020-09-25  8:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 15:32 John Alexander
2020-09-24 15:43 ` Bruce Richardson
2020-09-25  7:31   ` Morten Brørup
2020-09-25  8:41     ` Bruce Richardson [this message]
2020-09-25  8:58       ` Morten Brørup
2020-09-25  9:19       ` Dmitry Kozlyuk
2020-09-25  9:22         ` Bruce Richardson
  -- strict thread matches above, loose matches on Subject: below --
2020-09-24 14:22 John Alexander
2020-09-24 14:38 ` Bruce Richardson
2020-10-09 15:59 ` Bruce Richardson
2020-10-09 16:15   ` John Alexander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200925084122.GA923@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=John.Alexander@datapath.co.uk \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).