From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id D61F05A1D for ; Wed, 4 Mar 2015 18:03:36 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 04 Mar 2015 09:01:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,688,1418112000"; d="scan'208";a="462485134" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by FMSMGA003.fm.intel.com with ESMTP; 04 Mar 2015 08:57:15 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 4 Mar 2015 09:03:30 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.112]) by FMSMSX114.amr.corp.intel.com ([169.254.6.171]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 09:03:29 -0800 From: "Wiles, Keith" To: "Wiles, Keith" , Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] External app builds need to locate common make fragments and includes. Thread-Index: AQHQVlrSPHLvzaWZM0qNI4usK2HhE50MoLGAgABsoAD//51jgIAABF8A Date: Wed, 4 Mar 2015 17:03:28 +0000 Message-ID: References: <1425142563-27185-1-git-send-email-keith.wiles@intel.com> <54F6CB84.2050202@6wind.com> <54F7358C.2010403@6wind.com> In-Reply-To: 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: <92A7F6F2CF5B1349AFBBCBED2DABEB7E@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:03:37 -0000 On 3/4/15, 10:47 AM, "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 :-) 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 >> >