From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5566DA04F0; Tue, 10 Dec 2019 12:07:21 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4585437A2; Tue, 10 Dec 2019 12:07:20 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id EF85EA3 for ; Tue, 10 Dec 2019 12:07:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575976037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CFhrc+OyfG0HroDp+fLyqGBhd3p9260rU/UN5UHFnBw=; b=DYDv1EfjNlHaXVx8bbpH/gE6DXoFoNS9qoxDHNLrbEjDs0ikYEDRMKZ1eQtX/+wO0YP6gn aJN+9u+ahlYtny2bPlnqzgQn+53eOW2SAt4R2xY2I7erIbec7mbZtG9WlCRqaBq9cqzmsv TQ26pIcwH0RCkfoqCwDdsttyZhhh91g= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-345-MywIrcVtPDq9NTdKMJEpRQ-1; Tue, 10 Dec 2019 06:07:14 -0500 Received: by mail-ua1-f71.google.com with SMTP id q23so4860882uar.4 for ; Tue, 10 Dec 2019 03:07:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CFhrc+OyfG0HroDp+fLyqGBhd3p9260rU/UN5UHFnBw=; b=KHgpgxDP9QbmYdoJESYZAdUuKpDLMOIMjFt8OXUD87njqNiqyT4Rzu9mhyLUC5Ww1L lLX2QuMBLhqHvlgQfpyC3pk+ZSqq9p9EfVlAxOKu6heTg7Yt5IWNOxdivD+5atk8rRUH +mgCHBk7LpTYaGkm/gKsZeTW/5dV9hGBy7H7FSOpub2o2/miSLNqdYVm1sJxWv+NJHjH uyrZrL7kcts2/XFiKSfXT664qHVfh5H7SDod5RHcTuXNedwTeOKRZj9/zjY2K5VsIKDs frx8InCJErrqsJAARTNZeWdX1jzqS+JsSmQMA+s+P/tdmenKGlF4q6hR5dGghwwBB8YP M0Ag== X-Gm-Message-State: APjAAAW7zfVsSTfmZ+hDm70c9iYp138V/7cEf2fY0U99FLd4YsAcJ5no y26x2OCyYksu4BlQdxHVXeU7QwLcRrPLFh8eYqfZBKL+MtTT7abMzMTsAIvFAS3o4XXT3RmprEa qCTqUyq6bxSxNJkSkXVk= X-Received: by 2002:ab0:2408:: with SMTP id f8mr28741680uan.126.1575976033940; Tue, 10 Dec 2019 03:07:13 -0800 (PST) X-Google-Smtp-Source: APXvYqzgPVHYZ7N8nya7hdmXoLQtNPejBXFlZ4go0fswACujOG6LSM/JYJY/qpgJz68hj6pivMni6p+u07MCVz7PG9g= X-Received: by 2002:ab0:2408:: with SMTP id f8mr28741650uan.126.1575976033481; Tue, 10 Dec 2019 03:07:13 -0800 (PST) MIME-Version: 1.0 References: <20191129171024.56165-1-kevin.laatz@intel.com> <20191129210905.1865-1-kevin.laatz@intel.com> In-Reply-To: From: David Marchand Date: Tue, 10 Dec 2019 12:07:02 +0100 Message-ID: To: "Laatz, Kevin" Cc: dev , Thomas Monjalon , Bruce Richardson , "Kinsella, Ray" X-MC-Unique: MywIrcVtPDq9NTdKMJEpRQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3 0/7] Add ABI compatibility checks to the meson build X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Dec 3, 2019 at 4:27 PM Laatz, Kevin wrote: > > On 03/12/2019 11:03, David Marchand wrote: > > On Fri, Nov 29, 2019 at 10:09 PM Kevin Laatz wr= ote: > >> With the recent changes made to stabilize ABI versioning in DPDK, it w= ill > >> become increasingly important to check patches for ABI compatibility. = We > >> propose adding the ABI compatibility checking to be done as part of th= e > >> build. > >> > >> The advantages to adding the ABI compatibility checking to the build a= re > >> two-fold. Firstly, developers can easily check their patches to make s= ure > >> they don=E2=80=99t break the ABI without adding any extra steps. Secon= dly, it > >> makes the integration into existing CI seamless since there are no ext= ra > >> scripts to make the CI run. The build will run as usual and if an > >> incompatibility is detected in the ABI, the build will fail and show t= he > >> incompatibility. As an added bonus, enabling the ABI compatibility che= cks > >> does not impact the build speed. > >> > >> The proposed solution works as follows: > >> 1. Generate the ABI dump of the baseline. This can be done with the ne= w > >> script added in this RFC. This step will only need to be done when= the > >> ABI version changes (so once a year) and can be added to master so= it > >> exists by default. This step can be skipped if the dump files for = the > >> baseline already exist. > >> 2. Build with meson. If there is an ABI incompatibility, the build wil= l > >> fail and print the incompatibility information. > >> > >> The patches accompanying this RFC add the ABI dump file generating scr= ipt, > >> the meson option required to enable/disable the checks, and the requir= ed > >> meson changes to run the compatibility checks during the build. > > Global comments: > > - why are patch 1 and 2 in this series, is this really needed? > Not if we make this an 'auto' option. It would have needed debug info to > do the ABI check. > > - please squash patches 3, 4, 5 and 6, reading them separately is a > > pain and they are quite small, > Will do > > - if Windows does not support the ABI check, enforce this earlier in > > meson and refuse enabling it rather than silently ignoring it, > Makes sense, will look into this. > > - I would not enable this check by default > > - this is a developer option, people just building the dpdk don't > > care about it, > > - can we have something like a tristate "auto" (default, triggers > > the check if abidiff is installed), "disabled" and "enabled" (not > > having abidiff installed triggers an error) ? > Seems reasonable, will change. > > - please update the travis packages so that we can run those checks > > for developers submitting patches > Will do. > > - I don't think you tested this series with > > devtools/test-meson-builds.sh, please do. It fails with a custom build > > directory and in the dpdk tree too: > > > > Build targets in project: 1019 > > WARNING: Project specifies a minimum meson_version '>=3D 0.47.1' but > > uses features which were added in newer versions: > > * 0.48.0: {'console arg in custom_target'} > > * 0.50.0: {'install arg in configure_file'} > > Found ninja-1.9.0 at /usr/bin/ninja > > ninja -C /home/dmarchan/builds/build-gcc-static > > ninja: Entering directory `/home/dmarchan/builds/build-gcc-static' > > [48/2291] Generating librte_kvargs.abi_chk with a meson_exe.py custom c= ommand. > > FAILED: lib/librte_kvargs.abi_chk > > /usr/bin/meson --internal exe > > /home/dmarchan/builds/build-gcc-static/meson-private/meson_exe_abidiff_= 6511538ddd95d9672028017110fa45c67f01f7be.dat > > file /home/dmarchan/dpdk/lib/abi/librte_kvargs.dump does not exist > > [77/2291] Compiling C object > > 'lib/76b5a35@@rte_mbuf@sta/librte_mbuf_rte_mbuf.c.o'. > > ninja: build stopped: subcommand failed. > > This is failing as the .dump files have not been created yet. They can > be generated with devtools/gen-abi-dump.sh . This will > generate a .dump file for each shared object in the builddir drivers and > lib folders. Pinging on this series, since the sooner we integrate it, the better. We also need those dump files as part of the series, as it is not obvious what reviewers (at least me :-)) should do about them. Please can you work on a new revision? Thanks. -- David Marchand