19/12/2019 22:58, David Marchand: > On Fri, Dec 13, 2019 at 5:41 PM Kevin Laatz <kevin.la...@intel.com> wrote: > > The proposed solution works as follows: > > 1. Generate the ABI dump of the baseline. This can be done with the new > > script added in this set. This step will only need to be done when the > > ABI version changes (so once a year) and can be added to master so it > > exists by default. This step can be skipped if the dump files for the > > baseline already exist. > > 2. Build with meson. If there is an ABI incompatibility, the build will > > fail and print the incompatibility information. [...] > - I asked for the dump files, but I can see that it is impractical. > > The dump files are huge. I did not expect that :-). > The dump files are architecture specific and maintaining multi arch > dumps would be even bigger than just what you sent for x86_64. > (not even considering the changes in ABI if some configuration items > have an impact...).
I agree that dump files are better managed outside of git. > As you pointed out, people who don't have all dependencies won't > create/update those dump files. > Dealing with ABI updates (thinking of bumping the ABI version) is > likely a maintainer job, but it will be a source of issues and we > (maintainers) might miss some updates especially for drivers we can't > build. > > > - Why do we restrict the checks to meson? > The make build framework is going to disappear ok, but we can't leave > it untested. > People still rely on it. > > Checking the ABI is orthogonal to building DPDK. > Dumping the ABI and checking it against objects can be done externally. I agree we should not rely on meson for running the check. > - For those reasons, I have been trying an alternate approach [1]: in > Travis, generate a reference dump based on the first ancestor tag, > then build the proposed patches. > All contributions get picked up by Aaron robot and would have to pass > through this check. > > As an exercise, I tried to integrate Eelco patch [2], that moves > symbols from EXPERIMENTAL to a stable ABI. The check passes fine. > I also tried to bump the ABI major version. The check fails, as > expected, but I prepared a way to bypass such failures for the > releases where we will explicitely break ABI. > > For maintainers that integrate patches or developers that get a CI > failure and want to fix it, we would need to help them to: > * generate dumps on a reference version, so I would tend to write some > documentation since playing with the current sources would be too > dangerous from my pov, > * run the checks, like adding the check in the > devtools/test-*-build.sh scripts that already exist, with a new > configuration item to point at the dumps per target, We can start with a documented process, and write a separate script later if we feel it helps. > Those last two points are still to be done. > > WDYT? > > > 1: > https://github.com/david-marchand/dpdk/commit/f18de2ec157f3cc1e7b319cb19700e1b5e9cecde > 2: https://patchwork.dpdk.org/patch/63970/ Thanks to both of you trying some approaches and making progress.
