> From: dev [mailto:dev-boun...@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-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. > > > 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
