[v7,0/4] devtools: abi breakage checks

  This patchset introduces changes to test-meson-builds.sh, check-abi.sh and
adds a new script gen-abi-tarballs.sh. The changes to test-meson-builds.sh
include UX improvements such as adding command line arguments and allowing
the use of relative paths. Reduced the number of abi checks to just two,
one for both x86_64 and ARM, the references for these tests can now be
prebuilt and downloaded by test-meson-builds.sh, these changes will allow
the tests to run much faster. check-abi.sh is updated to use the prebuilt
references. gen-abi-tarballs.sh is a new script to generate the prebuilt
abi references used by test-meson-builds.sh, these compressed archives can
be retrieved from either a local directory or a remote http location.

---
v7: Changes resulting from list feedback

v6: Corrected a mistake in the doc patch

v5:
 - Patchset has been completely reworked following feedback
 - Patchset is now part of test-meson-builds.sh not the meson build
   system

v4:
 - Reworked both Python scripts to use more native Python functions
   and modules.
 - Python scripts are now in line with how other Python scripts in
   DPDK are structured.

v3:
 - Fix for bug which now allows meson < 0.48.0 to be used
 - Various coding style changes throughout
 - Minor bug fixes to the various meson.build files

v2: Spelling mistake, corrected spelling of environmental

Conor Walsh (4):
  devtools: add generation of compressed abi dump archives
  devtools: abi and UX changes for test-meson-builds.sh
  devtools: change dump file not found to warning in check-abi.sh
  doc: test-meson-builds.sh doc updates

 devtools/check-abi.sh               |   3 +-
 devtools/gen-abi-tarballs.sh        |  48 ++++++++
 devtools/test-meson-builds.sh       | 171 ++++++++++++++++++++++------
 doc/guides/contributing/patches.rst |  26 +++--
 4 files changed, 202 insertions(+), 46 deletions(-)
 create mode 100755 devtools/gen-abi-tarballs.sh
  

Hi David,

Came across an issue with this.

Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
is not guaranteed to be 100% compatible with a older versions.

That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
or libabigail version depending on how you look at it. 

An alter approach suggested by Dodi would be to just archive the binaries somewhere instead, 
and regenerate the dumps at build time. That _may_ be feasible, 
but you lose some of the benefit (build time saving) compared to archiving the abi dumps. 

The most sensible approach to archiving the binaries.
is to use DPDK release os packaging for this, installed to a fs sandbox. 

So the next steps are figuring out, which is the better option between 
maintaining multiple abi dump archives, one per supported os distro. 
or looking at what needs to happen with DPDK os packaging. 

So some work still to do here. 

Thanks,

Ray K
  

On Tue, Nov 3, 2020 at 11:07 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
> Came across an issue with this.
>
> Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
> is not guaranteed to be 100% compatible with a older versions.
>
> That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
> or libabigail version depending on how you look at it.

This is something I had encountered.

The Travis script flushes the ABI cache on a libabigail version change.
When using the test-meson-builds.sh integration, the gen-abi.sh
devtools script can be called to regenerate the dump files from the
existing local binaries.


>
> An alter approach suggested by Dodi would be to just archive the binaries somewhere instead,
> and regenerate the dumps at build time. That _may_ be feasible,
> but you lose some of the benefit (build time saving) compared to archiving the abi dumps.
>
> The most sensible approach to archiving the binaries.
> is to use DPDK release os packaging for this, installed to a fs sandbox.
>
> So the next steps are figuring out, which is the better option between
> maintaining multiple abi dump archives, one per supported os distro.
> or looking at what needs to happen with DPDK os packaging.
>
> So some work still to do here.

I am still unconvinced about the approach, but I'll wait for your next proposal.
  

On 10/11/2020 12:53, David Marchand wrote:
> On Tue, Nov 3, 2020 at 11:07 AM Kinsella, Ray <mdr@ashroe.eu> wrote:
>> Came across an issue with this.
>>
>> Essentially what is happening is that an ABI dump file generated with a newer versions of libabigail
>> is not guaranteed to be 100% compatible with a older versions.
>>
>> That then adds a wrinkle that we need may need to look at maintaining abi dump archives per distro release,
>> or libabigail version depending on how you look at it.
> 
> This is something I had encountered.
> 
> The Travis script flushes the ABI cache on a libabigail version change.

Why would the libabigail version change in Travis - due do an OS update or the like?

> When using the test-meson-builds.sh integration, the gen-abi.sh
> devtools script can be called to regenerate the dump files from the
> existing local binaries.
> 
> 
>>
>> An alter approach suggested by Dodi would be to just archive the binaries somewhere instead,
>> and regenerate the dumps at build time. That _may_ be feasible,
>> but you lose some of the benefit (build time saving) compared to archiving the abi dumps.
>>
>> The most sensible approach to archiving the binaries.
>> is to use DPDK release os packaging for this, installed to a fs sandbox.
>>
>> So the next steps are figuring out, which is the better option between
>> maintaining multiple abi dump archives, one per supported os distro.
>> or looking at what needs to happen with DPDK os packaging.
>>
>> So some work still to do here.
> 
> I am still unconvinced about the approach, but I'll wait for your next proposal.
> 
>
  

On Tue, Nov 10, 2020 at 2:54 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
> > The Travis script flushes the ABI cache on a libabigail version change.
>
> Why would the libabigail version change in Travis - due do an OS update or the like?

Because in Travis, we compiled our own version of libabigail, the one
in ubuntu 18.04 being buggy (opened some bug, never got any feedback).
I had left automatic flush to test different versions.