From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 50FDF2C17
 for <dev@dpdk.org>; Wed,  7 Jun 2017 14:07:55 +0200 (CEST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 07 Jun 2017 05:07:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.39,311,1493708400"; d="scan'208";a="1157627312"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.28])
 by fmsmga001.fm.intel.com with SMTP; 07 Jun 2017 05:07:52 -0700
Received: by  (sSMTP sendmail emulation); Wed, 07 Jun 2017 13:07:52 +0100
Date: Wed, 7 Jun 2017 13:07:51 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: "Hunt, David" <david.hunt@intel.com>, dev@dpdk.org, thomas@monjalon.net
Message-ID: <20170607120751.GA59616@bricha3-MOBL3.ger.corp.intel.com>
References: <1495535304-159542-3-git-send-email-david.hunt@intel.com>
 <1495788764-37652-1-git-send-email-david.hunt@intel.com>
 <1495788764-37652-2-git-send-email-david.hunt@intel.com>
 <dffa95fe-e251-5fc5-0a59-3b41d71f56e7@intel.com>
 <ef07f4e9-6a88-5ac6-8f00-04a573dfaebd@nxp.com>
 <ccf49fb3-032b-f5aa-62a0-ebb32086b3f7@intel.com>
 <9f34de63-beea-fdd6-47c4-4ce3a8208b02@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9f34de63-beea-fdd6-47c4-4ce3a8208b02@nxp.com>
Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?=
 =?iso-8859-1?Q?opment?= Ireland Ltd.
User-Agent: Mutt/1.8.1 (2017-04-11)
Subject: Re: [dpdk-dev] [PATCH v2 1/2] mk: allow use of environment var for
 make config
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2017 12:07:56 -0000

On Wed, Jun 07, 2017 at 05:16:18PM +0530, Shreyansh Jain wrote:
> On Wednesday 07 June 2017 03:58 PM, Hunt, David wrote:
> > Hi Shreyansh,
> > 
> > 
> > On 7/6/2017 10:36 AM, Shreyansh Jain wrote:
> > > Hello David,
> > > 
> > > On Wednesday 07 June 2017 02:09 PM, Hunt, David wrote:
> > > > Shreyansh,
> > > > 
> > > >      I found an issue (or two) with this part of the patch, and
> > > > have a proposed solution.
> > > > 
> > > > 1. RTE_TARGET originally had a different meaning. It was used
> > > > for making examples, specifying the target directory of where
> > > > the SDK was built. It's not good to re-purpose this for
> > > > something else, as I'm doing in this patch. (even though I'm not
> > > > sure that variable is suitably named in the first place, but
> > > > that's a different issue).
> > > 
> > > Even I didn't realize this until you highlighted here.
> > > 
> > > > 2. If we set RTE_TARGET on the environment, we will break the
> > > > 'make -C examples/<app>', unless we set RTE_TARGET to be
> > > > something else (i.e. 'make -C examples/<app> RTE_TARGET=build').
> > > > One value for making DPDK, and another for building examples.
> > > > It's confusing to the user.
> > > 
> > > Agree about re-using RTE_TARGET is breaking existing assumption about
> > > its use.
> > > 
> > > > 
> > > > An alternative patch would be as follows:
> > > > 
> > > >   RTE_CONFIG_TEMPLATE :=
> > > >   ifdef T
> > > > *-ifeq ("$(origin T)", "command line")*
> > > >   RTE_CONFIG_TEMPLATE := $(RTE_SRCDIR)/config/defconfig_$(T)
> > > > *-endif**
> > > > *endif
> > > >   export RTE_CONFIG_TEMPLATE
> > > So, that would mean, user would do either of the following:
> > > 
> > > make T=<template> config
> > > 
> > > or
> > > 
> > > export T=<template>
> > > make config
> > > 
> > > Is that correct? (I tried it and it seems to be working fine)
> > > First method is same as today. For the second, I am just skeptical
> > > whether we should use such a small identifier ("T") or we have a new
> > > RTE_TEMPLATE.
> > > 
> > > Either way, I am OK. [export T=<template>] looks fine to me - in fact,
> > > on a second though, IMO, if T=<template> is provided as command
> > > line, it should also be acceptable as env variable.
> > > 
> > 
> > I did a quick poll here in the office and people feel that 'T' is too
> > short for an environment variable. RTE_TEMPLATE would be preferred, and
> > it's a sensible choice that does not conflict with RTE_TARGET.
> > 
> > So if we use RTE_TEMPLATE, we'd also have to put in a couple of lines
> > for the "make install" case, but it's still a small enough patch:
> > 
> > diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
> > index dbac2a2..a464b01 100644
> > --- a/mk/rte.sdkinstall.mk
> > +++ b/mk/rte.sdkinstall.mk
> > @@ -47,6 +47,10 @@ ifneq ($(MAKECMDGOALS),pre_install)
> >   include $(RTE_SDK)/mk/rte.vars.mk
> >   endif
> > 
> > *+ifndef T**
> > **+T := $(RTE_TEMPLATE)**
> > **+endif**
> > * ifdef T # defaults with T= will install an almost flat staging tree
> >   export prefix ?=
> >   kerneldir   ?= $(prefix)/kmod
> > 
> > 
> > diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
> > index 076a2d7..0b71a4e 100644
> > --- a/mk/rte.sdkroot.mk
> > +++ b/mk/rte.sdkroot.mk
> > @@ -63,6 +63,8 @@ ifdef T
> >   ifeq ("$(origin T)", "command line")
> >   RTE_CONFIG_TEMPLATE := $(RTE_SRCDIR)/config/defconfig_$(T)
> >   endif
> > *+else**
> > **+RTE_CONFIG_TEMPLATE := $(RTE_SRCDIR)/config/defconfig_$(RTE_TEMPLATE)**
> > * endif
> >   export RTE_CONFIG_TEMPLATE
> > 
> > So if T is provided on the command line, it takes priority.
> > If that seems reasonable to you, I'll push up a v3. :)
> 
> Sounds good to me.
> Feel free to add my signoff to v3.
> 
> > 

In another shameless plug, can you guys perhaps take a look at the RFC
I've just posted[1], as an option to move away from this whole area of
RTE_TARGET/RTE_SDK, and the complexity such as this that it brings. Let
me know any thoughts or comments you have.

Thanks,
/Bruce

[1] http://dpdk.org/ml/archives/dev/2017-June/067428.html