From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [PATCH 0/7] Add hierarchical support to make install
Date: Tue, 22 Sep 2015 16:40:33 +0200
Message-ID: <56016861.6060603@6wind.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
To: Panu Matilainen <pmatilai@redhat.com>,
 Mario Carrillo <mario.alfredo.c.arevalo@intel.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id EB16958EF
 for <dev@dpdk.org>; Tue, 22 Sep 2015 16:40:40 +0200 (CEST)
In-Reply-To: <56012A12.5030909@redhat.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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