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

["Wiles, Keith" <keith.wiles@intel.com>]

On 3/4/15, 10:47 AM, "Wiles, Keith" <keith.wiles@intel.com> wrote:

>Hi Olivier
>
>On 3/4/15, 10:40 AM, "Olivier MATZ" <olivier.matz@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@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 :-)

The file can not be replaced with a single include line as it already
includes rte.extvars.mk :-(

OK lets just move it to mk/internal and I will submit a patch for that
change.
>
>Regards
>++Keith
>>
>>Regards,
>>Olivier
>>
>