Re: ABI break checking in frameworks

[David Faure]

On mercredi 26 octobre 2016 23:54:33 CET Albert Astals Cid wrote:
> 2) Make it a manual step (sorry David), we could have a script that for
> every release downloads and compiles the tarballs of it and the previous
> version and runs abidiff on them.
> 
> 
> Currently I am kind of leaning towards 2, but that is not optimal either
> since you need a system that can compile all the frameworks (and actually
> compile them twice).

Well it wouldn't really be manual, it would be automated as part of the 
release process, and it would compare the output from release N with the 
output from release N-1, which would be left on the release server after a 
release. So it wouldn't be "compile twice", but "compile once".

However the bit I don't like is that any breakage would delay releases.
I would find the problem on release day, then send an email if it's in a 
framework I don't work on myself, and then I'd have to wait for a fix...

So yeah I'd much rather that this is part of build.kde.org indeed, if 
possible.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: ABI break checking in frameworks

[Albert Astals Cid]

El dijous, 27 d’octubre de 2016, a les 9:20:29 CEST, Jaroslaw Staniek va 
escriure:
> On 26 October 2016 at 23:54, Albert Astals Cid  wrote:
> > Does anyone have other ideas or thoughts on it?
> 
> ​Three things:
> - the Qt project has own solution for the checks, maybe worth looking
> - try to convert the compiler-specific decorated symbols to some uniform
> notation and compare just that
> - add support for ignoring some errors (per line) and check them differently

Let's not reinvent the wheel when there's more than valid projects to do that 
:)

Cheers,
  Albert

Re: ABI break checking in frameworks

[Jaroslaw Staniek]

On 26 October 2016 at 23:54, Albert Astals Cid  wrote:

>
>
>
> Does anyone have other ideas or thoughts on it?
>
>
​Three things:
- the Qt project has own solution for the checks, maybe worth looking
- try to convert the compiler-specific decorated symbols to some uniform
notation and compare just that
- add support for ignoring some errors (per line) and check them differently

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

Re: ABI break checking in frameworks

[Bhushan Shah]

Hello Albert,

On Wed, Oct 26, 2016 at 11:54:33PM +0200, Albert Astals Cid wrote:
> 1) Have a helper repository where we upload the XML files of the ABIs exactly 
> produced by the CI nodes and then make CI check against that on every build.
> 
> This still has some issues on how we actually fill that helper repository 
> initially, but i guess it could be done
> 

In theory we can just store the XML files on build.kde.org master server
itself, and compare it next build, we don't really need helper
repository where we commit those xml files.

build.kde.org board on phabricator already have todo item for this
issue, https://phabricator.kde.org/T3689

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

ABI break checking in frameworks

[Albert Astals Cid]

Hi there, one of the things we say we maintain but we don't really have 
autotests for is maintaining ABI compatibility.

I recently learnt about abigail, a tool that for checking ABI compatibility.

Basically we are interested in two tools abidw and abidiff

abidw creates an XML file with the ELF representation of a file (compiled with 
debug mode)

abidiff diffs two XML files and gives you an output on what changed

The obvious problem with this an CI is that you need the XML file of the 
previous version to check if something has changed.

Also one can not simply commit the XML file to the repository for everyone to 
use since different compilers can have different ABIs (i.e. gcc 5 broke the C+
+11 ABI).

I see two ways forward:

1) Have a helper repository where we upload the XML files of the ABIs exactly 
produced by the CI nodes and then make CI check against that on every build.

This still has some issues on how we actually fill that helper repository 
initially, but i guess it could be done


2) Make it a manual step (sorry David), we could have a script that for every 
release downloads and compiles the tarballs of it and the previous version and 
runs abidiff on them.


Currently I am kind of leaning towards 2, but that is not optimal either since 
you need a system that can compile all the frameworks (and actually compile 
them twice).


Does anyone have other ideas or thoughts on it?

Cheers,
  Albert