> From: dev [mailto:dev-boun...@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.richard...@intel.com> > > To: John Alexander <john.alexan...@datapath.co.uk> > > Cc: "dev@dpdk.org" <dev@dpdk.org>, techbo...@dpdk.org > > Subject: Re: [dpdk-dev] Meson Minimum Version > > Message-ID: <20200924143830.gd...@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/ >
