[dpdk-dev] [PATCH] External app builds need to locate common make fragments and includes.

[Wiles, Keith]

Hi Olivier,

On 3/4/15, 11:04 AM, "Olivier MATZ" <olivier.matz at 6wind.com> wrote:

>Hi Keith,
>
>On 03/04/2015 05:47 PM, Wiles, Keith wrote:
>> Hi Olivier
>>
>> On 3/4/15, 10:40 AM, "Olivier MATZ" <olivier.matz at 6wind.com> wrote:
>>
>>> Hi Keith,
>>>
>>> On 03/04/2015 05:11 PM, Wiles, Keith wrote:
>>>>
>>>>
>>>> On 3/4/15, 3:08 AM, "Olivier MATZ" <olivier.matz at 6wind.com> wrote:
>>>>
>>>>> Hi Keith,
>>>>>
>>>>> On 02/28/2015 05:56 PM, Keith Wiles wrote:
>>>>>> When building an external application like Pktgen and using the
>>>>>>proper
>>>>>> makefile fragments rte.extXYZ.mk NOT rte.XYZ.mk files as you would
>>>>>> use with example applications in the same RTE_SDK directory the
>>>>>> rte.extXYZ.mk
>>>>>> files are missing some defines/includes.
>>>>>>
>>>>>>      1 - Add missing tests for RTE_SDK/RTE_TARGET not defined code.
>>>>>>      2 - The build of external applications are forced to be verbose
>>>>>> ouput
>>>>>>          as the Q=@ define is not present.
>>>>>>      3 - Missing include of target/generic/rte.vars.mk file which
>>>>>> includes
>>>>>>          the information to locate the rte_config.h and other DPDK
>>>>>> include
>>>>>>          files.
>>>>>>
>>>>>> A patch like this one was submitted before and was rejected because
>>>>>>it
>>>>>> seemed it was not required, because target/generic/rte.vars.mk
>>>>>>already
>>>>>> included by rte.vars.mk.
>>>>>>
>>>>>> This is not the cause for external applications like Pktgen which
>>>>>>are
>>>>>> built outside of the RTE_SDK directory and only include the
>>>>>> rte.extXYZ.mk
>>>>>> makefile fragments.
>>>>>
>>>>> I still not understand what is your problem. If you take an example
>>>>> from
>>>>> dpdk, let's say examples/l2fwd.
>>>>>
>>>>>     cd test
>>>>>     # compile dpdk
>>>>>     git clone http://dpdk.org/git/dpdk
>>>>>     cd dpdk
>>>>>     DPDK=${PWD}
>>>>>     make -j8 install T=x86_64-native-linuxapp-gcc
>>>>>     cd ..
>>>>>     # copy l2fwd in an external directory
>>>>>     cp -r dpdk/examples/l2fwd .
>>>>>     cd l2fwd
>>>>>     # build it
>>>>>     make RTE_TARGET=x86_64-native-linuxapp-gcc RTE_SDK=${DPDK}
>>>>
>>>> Yes, this very trivial example works, but only because the makefiles
>>>>are
>>>> combining the two different make fragments IMO.
>>>>
>>>> Then why do we have rte.extvars.mk fragment at all if it was not to be
>>>> used for building outside the DPDK build directory?
>>>> Why were the rte.extXYZ.mk make fragments created at all, but to
>>>> provide a
>>>> clean building system outside of DPDK build?
>>>>
>>>> It seem like to me we are combining two different build systems when
>>>> building the examples. If rte.extvars.mk is not used then lets delete
>>>>it
>>>> or replace it with a single line to include rte.vars.mk.
>>>>
>>>> IMO combining the two different make fragment styles is confusing and
>>>>we
>>>> need to remove rte.extvars.mk or replace it with my changes or replace
>>>> it
>>>> with a single line just to include rte.vars.mk, pick one.
>>>
>>> The examples and the documentation say to use "rte.vars.mk" for
>>>external
>>> applications. It's like this since the beginning, so changing the
>>> behavior now should be done with care to avoid breaking the working
>>> applications. I don't think it's a good idea.
>>>
>>> I would prefer to move add rte.extvars.mk in dpdk/mk/internal to avoid
>>> people doing this mistake again, what do you think?
>>
>> Instead of moving the file and someone using it anyway (as it is broke
>> IMO) lets just replace the content of the file with a single line
>>'include
>> rte.vars.mk' and we solve the problem. Plus this solves my symmetry
>> problem :-)
>
>I don't understand why would someone include this file directly?
>What is the reason you did that at the first place?
>Usually, people start from an example or the documentation, which are
>both correct.
>
>We cannot replace the content of rte.extvars.mk by an include to
>rte.vars.mk because currently rte.vars.mk includes rte.extvars.mk.
>To me, the only problem is that rte.extvars.mk should be marked as
>internal.
>
>Allowing to include rte.extvars.mk in dpdk to fix the behavior of
>pktgen makefiles does not seem to be a good argument. Why not fixing
>pktgen instead? What is broken in dpdk?

I just posted your point before you finished you email and will submit a
patch to move rte.extvars.mk to mk/rte.extvars.mk would that work?
>
>Regards,
>Olivier
>