DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Tomasz Duszynski <tdu@semihalf.com>
Cc: dev@dpdk.org, jck@semihalf.com, dima@marvell.com,
	nsamsono@marvell.com, jianbo.liu@arm.com,
	pablo.de.lara.guarch@intel.com
Subject: Re: [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson
Date: Wed, 18 Apr 2018 16:02:30 +0100	[thread overview]
Message-ID: <20180418150229.GA127664@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20180413161219.GB37024@bricha3-MOBL.ger.corp.intel.com>

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

  parent reply	other threads:[~2018-04-18 15:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-11 11:45 Tomasz Duszynski
2018-04-11 11:45 ` [dpdk-dev] [PATCH 1/2] net/mvpp2: rename the version file to standard Tomasz Duszynski
2018-04-11 11:45 ` [dpdk-dev] [PATCH 2/2] net/mvpp2: add meson build file Tomasz Duszynski
2018-04-13 16:12 ` [dpdk-dev] [PATCH 0/2] add MRVL MVPP2 PMD to meson Bruce Richardson
2018-04-13 16:14   ` Bruce Richardson
2018-04-18 15:02   ` Bruce Richardson [this message]
2018-04-19  8:55     ` Tomasz Duszynski
2018-04-19  8:58       ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180418150229.GA127664@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dima@marvell.com \
    --cc=jck@semihalf.com \
    --cc=jianbo.liu@arm.com \
    --cc=nsamsono@marvell.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=tdu@semihalf.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).