From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthew Hall <mhall-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org>
Subject: Re: [PATCH 0/4] Fix build issues with
 CONFIG_RTE_BUILD_COMBINE_LIBS=y
Date: Fri, 3 Oct 2014 14:21:50 -0700
Message-ID: <20141003212150.GA2637@mhcomputing.net>
References: <1412265386-26291-1-git-send-email-sergio.gonzalez.monroy@intel.com>
 <2041475.WSUx3LgNfR@xps13>
 <20141003081019.GA28988@sivswdev02.ir.intel.com>
 <2274825.SfVmqUQfpO@xps13>
 <20141003113234.GB24059@hmsreliant.think-freely.org>
 <20141003181713.GC1741@mhcomputing.net>
 <20141003191546.GD24059@hmsreliant.think-freely.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev-VfR2kkLFssw@public.gmane.org
To: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <20141003191546.GD24059-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev-VfR2kkLFssw@public.gmane.org>
List-Help: <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=subscribe>
Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org
Sender: "dev" <dev-bounces-VfR2kkLFssw@public.gmane.org>

On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote:
> With a single archive, you get everything you build even if you don't need 
> it.

Right, I was trying to avoid that for people who specifically didn't want it, 
if there are any... I'm not one of them.

> But presumably if you're building a static binary, you're
> likely building the dpdk as well and can configure optional libraries out of the
> build.  Separate libraries are more a need for downstream
> distributors/packagers, who use dynamic shared objects anyway.

Yeah, I was thinking it'd be nice if the downstream packagers could get a 
global '.a' and per-sublib '.a' as well. So that one dpdk package could be 
used by a client app which wanted everything, or only wanted portions.

> Backward compatibilty?  the DPDK doesn't yet provide run time compatibility
> between releases (something I've been trying to change).  Nobody provides
> compile time compatibility.  To do so would require fixing API's permenently.

Agreed. I was just advocating to avoid worsening the already existent issues. 
;)

Matthew.