[dpdk-dev,v2,1/2] mk: allow use of environment var for make config
Checks
Commit Message
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:
So if T is provided on the command line, it takes priority.
If that seems reasonable to you, I'll push up a v3. :)
Regards,
Dave.
Comments
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.
>
> Regards,
> Dave.
>
>
>
>
>
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
@@ -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
@@ -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