From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1F0CE7CC5 for ; Wed, 18 Apr 2018 17:02:34 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2018 08:02:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,465,1517904000"; d="scan'208";a="47951869" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by fmsmga001.fm.intel.com with SMTP; 18 Apr 2018 08:02:31 -0700 Received: by (sSMTP sendmail emulation); Wed, 18 Apr 2018 16:02:30 +0100 Date: Wed, 18 Apr 2018 16:02:30 +0100 From: Bruce Richardson To: Tomasz Duszynski Cc: dev@dpdk.org, jck@semihalf.com, dima@marvell.com, nsamsono@marvell.com, jianbo.liu@arm.com, pablo.de.lara.guarch@intel.com Message-ID: <20180418150229.GA127664@bricha3-MOBL.ger.corp.intel.com> References: <1523447107-13324-1-git-send-email-tdu@semihalf.com> <20180413161219.GB37024@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180413161219.GB37024@bricha3-MOBL.ger.corp.intel.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson 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: , X-List-Received-Date: Wed, 18 Apr 2018 15:02:35 -0000 On Fri, Apr 13, 2018 at 05:12:19PM +0100, Bruce Richardson wrote: > On Wed, Apr 11, 2018 at 01:45:05PM +0200, Tomasz Duszynski wrote: > > This patchseries adds MRVL MVPP2 PMD to meson build system. > > > > Tomasz Duszynski (2): > > net/mvpp2: rename the version file to standard > > net/mvpp2: add meson build file > > > > The patches look ok to me as far as the meson code is concerned, but I have > no way to test compilation etc. It doesn't cause issues with other x86 or > arm builds though, so: > > Series Acked-by: Bruce Richardson +Pablo, who is looking at the crypto driver which is similar. I've just realised at this stage - while looking at something similar with the turbo_sw baseband driver - that the use of environmental variables is probably going to cause us problems down the line here. In the case of cross-compilation, the meson build is going to pull the environment variable of the host, and use that, even in cases where there is no cross-compile library available. I think that for cases like this, using a build option is a better solution. It explicitly can be set for each independent build, avoiding the cross-build issues I refer to, and also prevents us having issues with changing the path in the environment and meson not recognising the change (environment variables are not tracked for reconfigure, unlike options). So, would you be ok with changing this to take the MUSDK path from a meson option rather than the environment? /Bruce