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 EE6DBA00C2;
	Wed, 22 Apr 2020 14:18:08 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id D3C3D1D5FD;
	Wed, 22 Apr 2020 14:18:08 +0200 (CEST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id EDEB01D5ED
 for <dev@dpdk.org>; Wed, 22 Apr 2020 14:18:07 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
 by mailout.nyi.internal (Postfix) with ESMTP id 9A1A15C014F;
 Wed, 22 Apr 2020 08:18:07 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Wed, 22 Apr 2020 08:18:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm1; bh=
 HiQhTXVOIhHLmMi6mukkx0RrYQ9ME8Za0S7vRKsIkTg=; b=dSV+CgOCdpz2t1oJ
 TGKPgCZ2o63VODFSU5MyQ61A0/PNCocPGdPfsa+XLrOem6R373Pj1ISQyK8HbvPl
 GNn9LNeOJ5obDam0G1yUt/EBeupJKXnwho18h14hbEgCVucxjABIZjzPB1S9eAVm
 pmd3OMyThU9wP9vzPqCrBwH29Fl9Z5ghuTRNcgJtixtpUClTUq90a8WTrzd1HuYr
 +P4TQpIgyk+xA67fPvHzNbodBRprHoNcmy6hYVRMYKzAwbTzrojvkt95JtgSDkMm
 jQBRDH6FVjEUE5aALB4bblfTcyp5RoaWClnve0PQx0wv/qIqRl9bSML23AmJHuzR
 CLesxg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm2; bh=HiQhTXVOIhHLmMi6mukkx0RrYQ9ME8Za0S7vRKsIk
 Tg=; b=Aeb0CuiT194JV8Gcbfql99kdBi8Mh7FQPqkQZPc0FHx+HaaePdkwBzvqD
 WpshJzRscueVsVXXNKurs0YMY8TnOIWep9ZpCQjioJ/2HkdGMTBn+VT7pWPPjMNN
 iOBP43+WbLwbxIG0vgEkuyeUvlU+bbo7Ct4DIErN1seY0mhhs8g4xJYe07F4/Uhk
 EtFYB4d1i+KJiCXcXWHAuSCVu0DUIL8wZPKS5msHj+cUiSBTA1oqj/NlsgdbfWTf
 oI4NHrspXDzsoW8Wb8RSK+Vk6fsFZTNy4jz3R6LJt3M9vgAico64LLfVvc1DiGWp
 gqsfJ9Z+7E47F6RlUeM9tyttRn0Rg==
X-ME-Sender: <xms:_zWgXo4I4kaCj6LCqCnxB2WbBPQIVCem_YJk96J-UbtmoFW8bym4wQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdegjecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph
 epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
 rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:_zWgXuIt-ullvSqPCaQXuNeJ18wOAqDJTva3AkzexJVASaRcTO999Q>
 <xmx:_zWgXieCwW4t_6PSSyDmMg2J6XE3jOdj_pSFc2tQtemIjH0U34sSmA>
 <xmx:_zWgXhd-RuAWDCIN3GG_XVclcEius48cDIBzxUXU1yCzYbA-xnbirg>
 <xmx:_zWgXsIxEwfc6Nt8f2Sb1PMHv_--8tJo5C7nUXLSZNjpb5Anr_jBmA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id BA3633065CD0;
 Wed, 22 Apr 2020 08:18:06 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org, david.marchand@redhat.com
Date: Wed, 22 Apr 2020 14:18:05 +0200
Message-ID: <1711842.QZUTf85G27@thomas>
In-Reply-To: <20200422120702.GB864272@hmswarspite.think-freely.org>
References: <20200416145414.262296-1-nhorman@tuxdriver.com>
 <a125f06f-6b8f-b39b-e51e-6a66ca8955ff@ashroe.eu>
 <20200422120702.GB864272@hmswarspite.think-freely.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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>

22/04/2020 14:07, Neil Horman:
> On Wed, Apr 22, 2020 at 12:43:44PM +0100, Ray Kinsella wrote:
> > On 21/04/2020 22:42, 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.
> > > 
> > 
> > So I can just relate my experience ....
> > 
> > root@silpixa00395806:/build/dpdk# DPDK_ABI_REF_VERSION=HEAD~1 ./devtools/test-meson-builds.sh
> > ninja -C ./build-gcc-static
> > ninja: Entering directory `./build-gcc-static'
> > [1766/2204] Compiling C object 'examples/c590b3c@@dpdk-vm_power_manager@exe/vm_power_manager_channel_monitor.c.o'.
> > ../examples/vm_power_manager/channel_monitor.c:22:9: note: #pragma message: Jansson dev libs unavailable, not including JSON parsing
> >  #pragma message "Jansson dev libs unavailable, not including JSON parsing"
> >          ^~~~~~~
> > [2204/2204] Linking target drivers/librte_pmd_softnic.so.20.0.2.
> > Cloning into 'reference/HEAD~1/src'...
> > warning: Could not find remote branch HEAD~1 to clone.
> > fatal: Remote branch HEAD~1 not found in upstream origin
> > fatal: The remote end hung up unexpectedly
> > 
> Ah, So its not the problem i was describing, I think the problem you are seeing
> is that the -b option only operates on branches and tags, not arbitrary git
> revisions.
> 
> To fix that, what we probably need to do is alter test-build.sh and
> test-meson-build.sh such that the git clone operation is preceded by something
> like this:
> git tag ABI_CHECK_TAG $DPDK_ABI_REF_VERSION
> 
> git clone ....
> 
> git tag -d ABI_CHECK_TAG
> 
> Doing so will guarantee that the source tree has a tag reference that the git
> clone operation can use to do a checkout with a -b option on.

I don't see the benefit of such test.
Can we just document that the reference must be an existing tag?