On 3/4/15, 10:47 AM, "Wiles, Keith" <keith.wiles at intel.com> 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 :-) 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 >> >
