From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>,
"John Alexander" <John.Alexander@datapath.co.uk>
Cc: <dev@dpdk.org>, <techboard@dpdk.org>
Subject: Re: [dpdk-dev] Meson Minimum Version
Date: Fri, 25 Sep 2020 09:31:53 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk> (raw)
In-Reply-To: <20200924154308.GF382@bricha3-MOBL.ger.corp.intel.com>
> 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.
> Regards,
> /Bruce
>
> PS: please don't top-post in replying and keep plain text email if
> possible. Thanks.
>
> > ------------------------------------------------------------------
> ----
> > Date: Thu, 24 Sep 2020 15:38:30 +0100
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > To: John Alexander <John.Alexander@datapath.co.uk>
> > Cc: "dev@dpdk.org" <dev@dpdk.org>, techboard@dpdk.org
> > Subject: Re: [dpdk-dev] Meson Minimum Version
> > Message-ID: <20200924143830.GD382@bricha3-MOBL.ger.corp.intel.com>
> > Content-Type: text/plain; charset=us-ascii
> > On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> > > Hi,
> > >
> > > I've submitted a patch that uses new features of Meson,
> specifically
> > the directory patch aspect of the subproject feature. This
> requires a
> > minimum Meson version of 0.55.0. How do we go about getting the
> > community to accept a more recent version of Meson and getting the
> > Travis server upgraded too so the CI builds succeed?
> > >
> > > Patch link for reference: http://patches.dpdk.org/patch/78675/
> > >
> > Hi John,
> > from what I understand the specific dependency on 0.55 is the
> support
> > for local patchfiles for the wrapped software, and that previous
> > versions only supported using patches pulled remotely - is that
> > correct?
> > While I'm in favour of incrementing the minimum meson version in
> > general, since 0.55 is the very latest version I am worried about
> any
> > impacts that might have, since it will basically mean that
> everyone
> > building DPDK has to pull meson from pip rather than being able to
> use
> > a distro-supplied version. Updating to something a little less
> recent
> > would be more my preference.
> > Then again, using the wrap system to pull in dependencies seems
> > something really good to have, so maybe the initial pain of
> requiring a
> > recent meson is worth it!
> > Thoughts from others?
> > Regards,
> > /Bruce
> >
> > John Alexander
> > Senior Software Engineer
> > Bemrose House, Bemrose Park, Wayzgoose Drive , Derby , DE21 6XQ
> > [1]+44 (0)1332 294 441 | [2]www.datapath.co.uk
> > [3]LinkedIn
> > [4]Twitter
> > [5]YouTube
> > [6]Vote for Datapath
> > Datapath Ltd. Registered Number: 1609392. Registered in England
> at Be
> > mrose House, Bemrose Park, Wayzgoose Drive, Derby. DE21 6XQ.
> >
> > References
> >
> > Visible links
> > 1. tel:+44%20(0)1332%20294%20441
> > 2. http://www.datapath.co.uk/
> > 3. https://www.linkedin.com/company/datapath-ltd
> > 4. https://www.twitter.com/datapathltd
> > 5. https://www.youtube.com/datapathderby
> > 6. https://nbmedia.wufoo.com/forms/z17utbme1olkvqz/
> >
> > Hidden links:
> > 7. http://www.datapath.co.uk/
>
next prev parent reply other threads:[~2020-09-25 7:31 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 [this message]
2020-09-25 8:41 ` Bruce Richardson
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=98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=John.Alexander@datapath.co.uk \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--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).