From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 239A0A04C0; Fri, 25 Sep 2020 10:41:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B91721E553; Fri, 25 Sep 2020 10:41:30 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id D442E1E551; Fri, 25 Sep 2020 10:41:28 +0200 (CEST) IronPort-SDR: yOluvbHMMUQ3dtdR91Jf5pDgO2/f4mDoZ09zQAbPqs9VsY6VdUK7cCMrAXQK4zfgs7ht2S7ip0 2VLLMFOU9alA== X-IronPort-AV: E=McAfee;i="6000,8403,9754"; a="223073552" X-IronPort-AV: E=Sophos;i="5.77,301,1596524400"; d="scan'208";a="223073552" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2020 01:41:27 -0700 IronPort-SDR: 5WsBb06ibkYKWSQAQGeQMp7TpRilYRun39BG3X7nNrzps2XMM8sucVKnWxWBOQD08L7WQLZwh4 2jvd7/ojgYmA== X-IronPort-AV: E=Sophos;i="5.77,301,1596524400"; d="scan'208";a="487384254" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.51.38]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 25 Sep 2020 01:41:26 -0700 Date: Fri, 25 Sep 2020 09:41:22 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: John Alexander , dev@dpdk.org, techboard@dpdk.org Message-ID: <20200925084122.GA923@bricha3-MOBL.ger.corp.intel.com> References: <20200924154308.GF382@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61326@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] Meson Minimum Version X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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