From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 2026A212 for ; Mon, 6 Oct 2014 16:38:35 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xb9XY-0001Fe-Bl; Mon, 06 Oct 2014 10:45:39 -0400 Date: Mon, 6 Oct 2014 10:45:31 -0400 From: Neil Horman To: Matthew Hall Message-ID: <20141006144531.GC22304@hmsreliant.think-freely.org> 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> <20141003212150.GA2637@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003212150.GA2637@mhcomputing.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:38:35 -0000 On Fri, Oct 03, 2014 at 02:21:50PM -0700, Matthew Hall wrote: > 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. > Fair enough Neil