From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH 0/2] add MRVL MVPP2 PMD to meson
Date: Wed, 18 Apr 2018 16:02:30 +0100
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
Cc: dev@dpdk.org, jck@semihalf.com, dima@marvell.com, nsamsono@marvell.com,
 jianbo.liu@arm.com, pablo.de.lara.guarch@intel.com
To: Tomasz Duszynski <tdu@semihalf.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 1F0CE7CC5
 for <dev@dpdk.org>; Wed, 18 Apr 2018 17:02:34 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <20180413161219.GB37024@bricha3-MOBL.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 <bruce.richardson@intel.com>

+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