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.
