From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id EB16958EF for ; Tue, 22 Sep 2015 16:40:40 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZeOkW-0007Qq-Va; Tue, 22 Sep 2015 16:40:53 +0200 Message-ID: <56016861.6060603@6wind.com> Date: Tue, 22 Sep 2015 16:40:33 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Panu Matilainen , Mario Carrillo , dev@dpdk.org References: <1442608390-12537-1-git-send-email-mario.alfredo.c.arevalo@intel.com> <5600F549.20000@redhat.com> <56010A91.5020607@6wind.com> <56011296.7060502@redhat.com> <56011898.6090207@6wind.com> <56012A12.5030909@redhat.com> In-Reply-To: <56012A12.5030909@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 0/7] Add hierarchical support to make install 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: Tue, 22 Sep 2015 14:40:41 -0000 Hi, On 09/22/2015 12:14 PM, Panu Matilainen wrote: > In my packaging of DPDK I ended up providing both: headers, libraries > etc in the normal system paths, and then a separate dpdk-sdk directory > holding the SDK-parts like mk bits and symlinking to the libs and > headers as needed, so that you can actually point RTE_SDK to that > dpdk-sdk dir and be able to build apps against the thing. Great, it didn't know that. >> My question is: do we want to keep the current install behavior for >> compatibility or not? Should we consider this makefile directive as >> an API? People may use it, and we should at least ask us it it should >> follow a sort of API deprecation process like we do for the code. >> That's why I talked about 2 new commands and deprecate the old one. > > I'd be surprised if somebody somewhere isn't relying on the current > specific behavior, given its explicitly documented and all. Whether it > needs to stay, and whether it needs to stay as the default ... I > wouldn't miss it, but its a question for those using and depending on it > really. Ok. So if nobody else complains, I have no objection to change the default behavior of "make install" to this which indeed looks more usual and distribution-friendly. In this case we may remove the old one, it's probably better than having a H=1 option. Regards, Olivier