16/01/2020 12:52, Neil Horman: > On Wed, Jan 15, 2020 at 01:38:17PM +0100, Thomas Monjalon wrote: > > 15/01/2020 12:33, Neil Horman: > > > On Wed, Jan 15, 2020 at 12:19:30AM +0100, Thomas Monjalon wrote: > > > > 20/12/2019 17:20, Kinsella, Ray: > > > > > From: Richardson, Bruce <bruce.richard...@intel.com> > > > > > > From: David Marchand <david.march...@redhat.com> > > > > > > > +Checking ABI compatibility > > > > > > > +-------------------------- > > > > > > > + > > > > > > > +The first thing is to build reference binaries for the latest > > > > > > release > > > > > > > +your patches are built on top of. > > > > > > > + > > > > > > > +Either you are in a git tree and an easy way to identify this is > > > > > > > to > > > > > > run:: > > > > > > > + > > > > > > > + git checkout $(git describe --abbrev=0) > > > > > > > + > > > > > > > +Or you use a tarball and you extract the sources in a director of > > > > > > > +your > > > > > > > choice. > > > > > > > + > > > > > > > +Next is building those sources, refer to the previous paragraph. > > > > > > > +You can set ``DPDK_BUILD_TEST_DIR=reference``, so that the builds > > > > > > > +occur in this directory. > > > > > > > + > > > > > > > +Finally, the ABI dump files are generated with the > > > > > > > +``devtools/gen-abi-reference.sh`` script. This script will look > > > > > > > for > > > > > > > +builds in the current sub directory ``reference``. But you can > > > > > > > set > > > > > > > +the environment variable ``DPDK_ABI_REF_BUILD_DIR`` to a > > > > > > > different > > > > > > location. > > > > > > > + > > > > > > > +Once done, you can check your current binaries ABI with this > > > > > > > +reference with the ``devtools/check-abi-reference.sh`` script. > > > > > > > > > > > > > > > > > > > I still very much dislike forcing the user to generate his own > > > > > > reference version to compare the ABI against. These should be > > > > > > archived > > > > > > and the user should just be able to pull them down via git or http > > > > > > or > > > > > > otherwise. Two reasons for this: > > > > > > > > > > > > 1. Less error prone, since there is no chance of the user having an > > > > > > incorrect build for whatever reason. > > > > > > > > > > > > 2. Less effort for the user than asking them to do extra builds. The > > > > > > more steps the user has to follow, the less likely they are to > > > > > > attempt > > > > > > the process. > > > > > > > > > > +1 ... 100% agree with this. > > > > > > > > > > Many people won't know or understand what the reference is, > > > > > or why they to generate it. > > > > > > > > I don't want to generate and save the reference in git for each arch. > > > > > > > Can I ask what your reluctance is? Is it related to not wanting to have > > > to save > > > all this information that is otherwise not used for building purposes? > > > > Yes I prefer keeping only the sources in the repository. > > And these dumps are big. > > And last but not the least, there is no ready-to-use environment to build > > and dump all libs for all archs. > > > > > If so I might suggest saving the dumps in a separate git tree and pulling > > > them > > > in as a git submodule when the check is performed > > > > > > I really like the idea of caching the results so everyone is working from > > > a > > > known ABI baseline. > > > > You don't trust the result of the build made from tagged sources? > > > I trust the result from the tools, sure, its trusting that people will take > the > extra time to build a version from a prior tag that I'm less sure of. > Consistent use in my mind is predicated on ease and timeliness of use. > > I get not wanting to store large dumps in the source tree, but storage is > cheap, > and I don't see the issue with storing the xml dump in a separate git tree to > be > referenced through a git submodule that gets pulled in when the check is run.
Yes this is an option. My fear is that this reference database will not be complete if we don't build it for all libraries/drivers on all archs, managing setups and dependencies.
