From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 53659DE4 for ; Mon, 6 Jul 2015 23:46:09 +0200 (CEST) Received: by wgck11 with SMTP id k11so151726954wgc.0 for ; Mon, 06 Jul 2015 14:46:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=esuW+/PimWFx5Uw9wn/yUynj3B1cjeBJac/Hol9/ruM=; b=BcfmpRHmK0gkeqzmdVmGUAG1HmRBoNJpz6PNHOpA7v1rJBMoX2qduz29MrsklqdSvi kunXB64dsVVWz22zeID78YNoaLIU1lQ88yM8ObwL1frM7apnlwGw9YuBaFp41s3dQ9lz zSYP39w8wF5xyjvDceGYejF0z3qFPXFzlHuobzoUzduxpjZKp6kKNETRXAWnKbX3mAOc czHXCPrrk6OL5PBixMXOIJLJVG5NogQ7DQZk5+wvL7Vx3eH9RqP7Rwth3lDDrxK03VkJ /vqTX9QomnHl/vv7vsv8orUDfZSPv6kgz3DzSAZrVFm+vfl3sadNjgwvbwOCgrOfv02A LYlA== X-Gm-Message-State: ALoCoQk62nhoEP/Mj4I1dDhZfYYOC+RgKeTmRCyLvOyEvohWsSpBZFbW62k0d3UtjQIOjOFnjwL+ X-Received: by 10.194.246.105 with SMTP id xv9mr1734512wjc.135.1436219169089; Mon, 06 Jul 2015 14:46:09 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id l7sm30615436wic.2.2015.07.06.14.46.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 14:46:08 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Mon, 06 Jul 2015 23:44:59 +0200 Message-ID: <33405606.8BIq3zMLWK@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150706182238.GC30816@hmsreliant.think-freely.org> References: <1435874746-32095-1-git-send-email-thomas.monjalon@6wind.com> <3961609.5kzAKlCGhe@xps13> <20150706182238.GC30816@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: enable next abi in static libs 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 Jul 2015 21:46:09 -0000 2015-07-06 14:22, Neil Horman: > On Mon, Jul 06, 2015 at 03:49:50PM +0200, Thomas Monjalon wrote: > > 2015-07-06 09:35, Neil Horman: > > > On Mon, Jul 06, 2015 at 03:18:51PM +0200, Thomas Monjalon wrote: > > > > Any comment or ack? > > > > > > > > 2015-07-03 00:05, Thomas Monjalon: > > > > > When a change makes really hard to keep ABI compatibility, > > > > > instead of waiting next release to break the ABI, it is smoother > > > > > to introduce the new code and enable it only for static libraries. > > > > > The flag RTE_NEXT_ABI may be used to "ifdef" the new code. > > > > > When the release is out, a dynamically linked application can use > > > > > the new shared libraries without rebuild while developpers can prepare > > > > > their application for the next ABI by reading the deprecation notice > > > > > and easily testing the new code. > > > > > When starting the next release cycle, the "ifdefs" will be removed > > > > > and the ABI break will be marked by incrementing LIBABIVER. > > > > > > > > > > The new option CONFIG_RTE_NEXT_ABI is not defined in the configuration > > > > > templates because it is deduced from CONFIG_RTE_BUILD_SHARED_LIB. > > > > > It is automatically enabled for static libraries and disabled for > > > > > shared libraries. > > > > > It can be forced to another value by editing the generated .config file. > > > > > It shouldn't be enabled for shared libraries because it would break the > > > > > ABI without changing the version number LIBABIVER. That's why a warning > > > > > is printed in this case. > > > > > > > > > > The guideline is also updated to integrate this new possibility. [...] > I'd be ok with it iff: > > 1) It applies to static and shared ABI's together. That is to say that setting > the NEXT_ABI config flag creates the same ABI changes regardless of other build > configuration. It needs to be used in such a way that a consistent ABI is > presented when set, otherwise it won't be useful. Yes the option trigger exactly the same ABI for static and shared libraries. But it's too complicated (at least for 2.1) to make LIBABIVER and version map dependant of this build-time option. That's why, it should not be enabled to deploy shared libraries, though it can be used for tests and development. As static libraries are almost never packaged, they will be built and linked at the same time. That's why users of static libraries tend to prefer the newest ABI, which is the default in this case. > 2) It only applies to the next ABI. That is to say, it can't be a hodgepodge of > the next ABI and the one after that, and the one after that, or it won't provide > an appropriate preview for anyone. If you mean the next ABI must be promoted as the standard ABI in the next release, yes: ifdefs will be cleaned when starting a new release. Thanks, I learnt the english word hodgepodge :)