From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 1AD635A76 for ; Wed, 4 Mar 2015 18:07:09 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 04 Mar 2015 09:06:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,688,1418112000"; d="scan'208";a="462487128" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by FMSMGA003.fm.intel.com with ESMTP; 04 Mar 2015 09:00:27 -0800 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 4 Mar 2015 09:06:42 -0800 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by ORSMSX158.amr.corp.intel.com (10.22.240.20) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 4 Mar 2015 09:06:42 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.112]) by fmsmsx120.amr.corp.intel.com ([169.254.15.131]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 09:06:42 -0800 From: "Wiles, Keith" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] External app builds need to locate common make fragments and includes. Thread-Index: AQHQVlrSPHLvzaWZM0qNI4usK2HhE50MoLGAgABsoAD//51jgIAAaTAA//+cFwA= Date: Wed, 4 Mar 2015 17:06:41 +0000 Message-ID: References: <1425142563-27185-1-git-send-email-keith.wiles@intel.com> <54F6CB84.2050202@6wind.com> <54F7358C.2010403@6wind.com> <54F73B10.40208@6wind.com> In-Reply-To: <54F73B10.40208@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.65.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <79CFB7E398FD2F4CA91F80139F26EDB2@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] External app builds need to locate common make fragments and includes. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:07:10 -0000 Hi Olivier, On 3/4/15, 11:04 AM, "Olivier MATZ" wrote: >Hi Keith, > >On 03/04/2015 05:47 PM, Wiles, Keith wrote: >> Hi Olivier >> >> On 3/4/15, 10:40 AM, "Olivier MATZ" wrote: >> >>> Hi Keith, >>> >>> On 03/04/2015 05:11 PM, Wiles, Keith wrote: >>>> >>>> >>>> On 3/4/15, 3:08 AM, "Olivier MATZ" 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=3D@ 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=3D${PWD} >>>>> make -j8 install T=3Dx86_64-native-linuxapp-gcc >>>>> cd .. >>>>> # copy l2fwd in an external directory >>>>> cp -r dpdk/examples/l2fwd . >>>>> cd l2fwd >>>>> # build it >>>>> make RTE_TARGET=3Dx86_64-native-linuxapp-gcc RTE_SDK=3D${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 >