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

[Thomas Monjalon <thomas@monjalon.net>]

22/04/2020 15:19, Ray Kinsella:
> On 22/04/2020 13:18, 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?
> > 
> You want people to use this thing right?

Yes, compare their own code with a well known tag.