Re: [dpdk-dev] [PATCHv3] Remove validate-abi.sh from tree

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Apr 22, 2020 at 02:18:05PM +0200, Thomas Monjalon wrote:
> 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?
> 
We could, but like Ray said, if you want people to use this, you'll want to make
it easy for them.  Many people will want to test the ABI against a well known
tag, but some are going to want to test against an arbitrary version (i.e.
against the merge base of their feature branch and the point they branched
from), which means they will attempt to check against an arbitrary hash value or
non-tag symbolic reference.  Theres no reason we can't enable that, the only
reason it doesn't work is because of an ideosyncracy of the git branch command,
and the above fixes that.

Neil

> 
>