From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by dpdk.org (Postfix) with ESMTP id CEE7C5683 for ; Wed, 4 Mar 2015 17:40:43 +0100 (CET) Received: by wesq59 with SMTP id q59so47591090wes.1 for ; Wed, 04 Mar 2015 08:40:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b2XMgMdK5KEcbRPVdRTt7DQgPMzBWbielyQ1hQCtOLc=; b=fN9AH8LtBaTQCdAdDiazlUP0E2TTX6CmJmb0WqTwug5VtWIgt0frQAXKg/2Fme2xrF o93OZ4x8+xA+coBLrXrYs2RVnOWwUxiaayUNj5RDL7nNLKDPuBo3X7ms6i2LqegnBU/O l2ayRXJJcu5odqq/La+O+eGfsBo28aM0OfdrZEdbwqY/sfFDXgvShd02ROQ68ji2/H/q atxQyVWfGIqY7Eowa5SSKuF2ezAFOU9upA0xZv/1SQCzmbiZ5Ss1RDBGGxEUz4zBl+uv 81ROvOMtXPq+CtZtNlw41glWOkqvWMAp6W1ZxGx5rexuqTGJnd8aO1F6A3Dc1J8f9wB8 kHEA== X-Gm-Message-State: ALoCoQkKXiTYvv0/8LJ5678Awz/tBnDNYalMd4pBT72i11eOLyzpYjc4J9o4OcyjKOR7Twt8Vx/K X-Received: by 10.194.58.84 with SMTP id o20mr9767439wjq.75.1425487243595; Wed, 04 Mar 2015 08:40:43 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id hv5sm6689411wjb.16.2015.03.04.08.40.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 08:40:43 -0800 (PST) Message-ID: <54F7358C.2010403@6wind.com> Date: Wed, 04 Mar 2015 17:40:44 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: "Wiles, Keith" , "dev@dpdk.org" References: <1425142563-27185-1-git-send-email-keith.wiles@intel.com> <54F6CB84.2050202@6wind.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 16:40:44 -0000 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=@ 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? Regards, Olivier