From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hunt, David" Subject: Re: [PATCH v3 1/3] mk: add sensible default target with defconfig Date: Fri, 4 Aug 2017 11:42:44 +0100 Message-ID: <70966f2e-16ee-0657-4d02-7ea0af755e22@intel.com> References: <1495788764-37652-2-git-send-email-david.hunt@intel.com> <2651056.W04Ra9JkEP@xps> <6606996c-f7b1-439f-aa73-8aeaa585f062@intel.com> <7428277.FEDDLdAvNx@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, "shreyansh.jain@nxp.com" To: Thomas Monjalon Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 360FF1F5 for ; Fri, 4 Aug 2017 12:42:46 +0200 (CEST) In-Reply-To: <7428277.FEDDLdAvNx@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/8/2017 11:05 AM, Thomas Monjalon wrote: > 04/08/2017 11:53, Hunt, David: >> On 4/8/2017 10:36 AM, Thomas Monjalon wrote: >>> 04/08/2017 10:22, Hunt, David: >>>> From: Thomas Monjalon [mailto:thomas@monjalon.net] >>>> 07/06/2017 16:37, David Hunt: >>>>> Users can now use 'make defconfig' to generate a configuration using >>>>> the most appropriate defaults for the current machine. >>>>> >>>>> >>>>> arch taken from uname -m >>>>> machine defaults to native >>>>> execenv is taken from uname, Linux=linuxapp, otherwise bsdapp >>>>> toolchain is taken from $CC -v to see which compiler to use >>>>> >>>>> Signed-off-by: David Hunt >>>>> Acked-by: Shreyansh Jain >>>> Looks to be a good idea if it is really automatic. >>>> >>>>> + ${CC} -v 2>&1 | \ >>>>> + grep " version " | cut -d ' ' -f 1) >>>> Unfortunately, it depends on $CC which is not commonly exported. >>>> What about defaulting to gcc? >>>> >>>>> - @echo "Configuration done" >>>>> + @echo "Configuration done using "$(shell basename \ >>>>> + $(RTE_CONFIG_TEMPLATE) | sed "s/defconfig_//g") >>>> RTE_CONFIG_TEMPLATE is not defined in this patch (and I do not see the benefit in next patch). >>>> >>>> Thomas, >>>> Does this mean that this patch is not going into this release? It has been acked for almost a month now, with no further comment. The one hour between your comment and the release of RC4 did not give me a reasonable amount of time to address your concerns. I also feel that the lack of comments in the last month should mean that the patch should be applied as is. If changes are required, I am happy to address in the next release. >>> You're right, I'm very sorry not taking time to review it before. >>> I think only the first patch should be integrated, without the comment for >>> RTE_CONFIG_TEMPLATE. >>> Opinion? >> OK, I would be OK with the first patch. However, I think the >> RTE_CONFIG_TEMPLATE comment part of the patch is fine, we just tested it >> here. It's only RTE_TEMPLATE I'm introducing in the second patch, nor >> RTE_CONFIG_TEMPLATE. That existed before this patch set. So the echo >> command in the first patch works fine, and shows the user what template >> the script has used to configure itself. > Ah OK I totally missed it :) > >> I could upload another patch with just the first patch (and the relevant >> 2 lines from the docs patch) as a v4? > Yes perfect > Thomas, OK, V5 sent. (v4 had 1 line missing in docs). There's just the one patch in the set now. Thanks, Dave.