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 >
