From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186])
 by dpdk.org (Postfix) with ESMTP id 95003E82
 for <dev@dpdk.org>; Fri,  3 Oct 2014 23:15:36 +0200 (CEST)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 1F0B680B615; Fri,  3 Oct 2014 14:21:50 -0700 (PDT)
Date: Fri, 3 Oct 2014 14:21:50 -0700
From: Matthew Hall <mhall@mhcomputing.net>
To: Neil Horman <nhorman@tuxdriver.com>
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
Content-Disposition: inline
In-Reply-To: <20141003191546.GD24059@hmsreliant.think-freely.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Fix build issues with
 CONFIG_RTE_BUILD_COMBINE_LIBS=y
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Fri, 03 Oct 2014 21:15:36 -0000

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.