From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id EF77DA00C3;
	Thu, 23 Apr 2020 12:57:46 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id C53E31D408;
	Thu, 23 Apr 2020 12:57:45 +0200 (CEST)
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id AA5EC1C2EC
 for <dev@dpdk.org>; Thu, 23 Apr 2020 12:57:44 +0200 (CEST)
Received: from 2606-a000-111b-6132-0000-0000-0000-1bf2.inf6.spectrum.com
 ([2606:a000:111b:6132::1bf2] helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1jRZXx-0006fT-7D; Thu, 23 Apr 2020 06:57:40 -0400
Date: Thu, 23 Apr 2020 06:57:32 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Ray Kinsella <mdr@ashroe.eu>, dev@dpdk.org, david.marchand@redhat.com
Message-ID: <20200423105732.GA990823@hmswarspite.think-freely.org>
References: <20200416145414.262296-1-nhorman@tuxdriver.com>
 <1695354.8hzESeGDPO@thomas>
 <20200422120108.GA864272@hmswarspite.think-freely.org>
 <1755319.1xdlsreqCQ@thomas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1755319.1xdlsreqCQ@thomas>
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
Subject: Re: [dpdk-dev] [PATCHv3] Remove validate-abi.sh from tree
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, Apr 22, 2020 at 02:16:57PM +0200, Thomas Monjalon wrote:
> 22/04/2020 14:01, Neil Horman:
> > On Tue, Apr 21, 2020 at 11:42:42PM +0200, Thomas Monjalon wrote:
> > > 21/04/2020 20:56, Neil Horman:
> > > > On Tue, Apr 21, 2020 at 01:46:43PM +0200, Thomas Monjalon wrote:
> > > > > 21/04/2020 13:12, Neil Horman:
> > > > > > On Fri, Apr 17, 2020 at 04:42:38PM +0100, Ray Kinsella wrote:
> > > > > > > On 17/04/2020 13:10, Thomas Monjalon wrote:
> > > > > > > > 17/04/2020 13:47, Ray Kinsella:
> > > > > > > >> On 17/04/2020 11:20, Thomas Monjalon wrote:
> > > > > > > >>> 17/04/2020 12:11, Ray Kinsella:
> > > > > > > >>>> check-abi.sh appears to be backward step in terms of usability.
> > > > > > > >>>
> > > > > > > >>> No, check-abi.sh benefits from a nice integration in build scripts.
> > > > > > > >>> See below.
> > > > > > > >>>
> > > > > > > >>>> With validate-abi.sh I do can do a "validate-abi.sh HEAD~1 HEAD".
> > > > > > > >>>> And it will do the build, install, dump and comparison for me. 
> > > > > > > >>>> And it picked up my 20.0.2 - > 21.0 changes no problem. 
> > > > > > > >>>>
> > > > > > > >>>> With check-abi on the other hand, I need to the build and install myself.
> > > > > > > >>>> check-abi requires dump files, but I see no reference in the documentation to how these are created.
> > > > > > > >>>> It silently fails when it doesn't find any ...
> > > > > > > >>>>
> > > > > > > >>>> Do I run abi-dumper on the so's myself, or how does it work?
> > > > > > > >>>
> > > > > > > >>> check-abi.sh is integrated in test-build.sh and test-meson-builds.sh.
> > > > > > > >>> Probably we should document usage in these scripts.
> > > > > > > >>
> > > > > > > >> Looks like I need to set DPDK_ABI_REF_VERSION=master, not obvious.
> > > > > > > >> Any tips or tricks would be welcome.
> > > > > > > > 
> > > > > > > > export DPDK_ABI_REF_VERSION=v20.02
> > > > > > > > or
> > > > > > > > export DPDK_ABI_REF_VERSION=v19.11
> > > > > > > > 
> > > > > > > > Depends on which compatibility you want to test...
> > > > > > > > 
> > > > > > > 
> > > > > > > Few things ...
> > > > > > > 
> > > > > > > 1. test-meson-build.sh keep barfing complaining about reference paths.
> > > > > > > ValueError: dst_dir must be absolute, got reference/v19.11/build-gcc-static/usr/local/share/dpdk/examples/bbdev_app
> > > > > > > 
> > > > > > > Under the hood, ninja install is failing complaining that it needs an absolute path.
> > > > > > > I fixed this in test_meson_build.sh and will send a patch in a minute. 
> > > > > > > Though it's strange no-one else has seen it?
> > > > > > > 
> > > > > > > 2. test-meson-build.sh compares the abi for the static builds, which doesn't make any sense. 
> > > > > > > 
> > > > > > > 3. test-meson-build.sh will only take a branch in DPDK_ABI_REF_VERSION that exists locally.
> > > > > > > In order to get it to compare HEAD against HEAD~1, which you would imagine is a pretty common case.
> > > > > > > I had a create a branch for HEAD~1, in validate-abi this a pretty simple `validate-abi HEAD~1 HEAD`
> > > > > > > 
> > > > > >  I think this code in test-meson-build.sh should probably be fixed:
> > > > > > 
> > > > > > if [ ! -d $abirefdir/src ]; then
> > > > > >                                 git clone --local --no-hardlinks \
> > > > > >                                         --single-branch \
> > > > > >                                         -b $DPDK_ABI_REF_VERSION \
> > > > > >                                         $srcdir $abirefdir/src
> > > > > >                         fi
> > > > > > 
> > > > > > Like you noted, using -b allows us to checkout a tag/branch in the cloned
> > > > > > repository but requires that it exist locally.  We should probably prefix the
> > > > > > checkout with a git fetch --tags
> > > > > 
> > > > > I don't understand your concern.
> > > > > A reference is an older version, so it should be in the git tree.
> > > > > 
> > > > yes, but not unless you've done a recent pull or fetch.  If you set
> > > > DPDK_ABI_REF_VERSION to a tag/branch that didn't exist as of the last time you
> > > > updated the tree, it won't be there (which it sounds like what is being
> > > > encountered here).  You can fix that by doing a git pull or git fetch prior to
> > > > running this script (or internal to the script)
> > > 
> > > Sorry I still don't understand the case.
> > > We want to compare the current version C with a reference R which is older.
> > > If the reference R is not in the tree, it means the version C is not in the tree.
> > > But C is the current version, so it is in the tree by definition.
> > > 
> > 
> > 
> >                                       +---+
> >                                       |   |
> > +---+                                 |   | DPDK 20.11
> > |   |Feature Branch commit            +-+-+
> > |   |                                   |
> > +-+-+   +---+                         +-v-+
> >   |     |   | master HEAD             |   | master HEAD
> >   |     +-+-+                         +-+-+
> >   |       |                             |
> >   |       |                             |
> >   |     +-v-+                         +-v-+
> >   +---->+   | DPDK 19.11              |   | DPDK 19.11
> >         +---+                         +---+
> > X                   X         X                   X
> > XXXXXXX     XXXXXXXXX         XXXXXXX     XXXXXXXXX
> >       XXX  XX                       XXX  XX
> >         XXXX                          XXXX
> > 
> >      Local GIT copy                 DPDK.ORG
> > 
> > 
> > 
> > If a user clones from dpdk.org when dpdk 19.11 is tagged in the tree, or any
> > time before dpdk 20.11 is tagged, then creates a feature branch, they may want
> > to compare their abi to the latest stable version.  If they check dpdk.org and
> > see that dpdk 20.11 is the latest tag in the tree, they can run check-abi.sh
> > with the reference tag specified as 20.11, which exists in the dpdk.org tree,
> > but may not have been pulled into their local copy yet.
> > 
> > I'm not saying this is definately what happened, but it would explain the
> > reported observations.
> 
> OK now I understand.
> The user specified a reference which is not in his local tree.
> I vote for considering this case as an user mistake,
> and document it as a limitation of the tool integration in our build
> testing scripts.
> 
I'd be fine with that, given that this turned out to not be rays issue.
Neil

> 
>