[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stable ABI checking (take 2)



On 22.02.2021 17:00, Andrew Cooper wrote:
> On 22/02/2021 14:37, Jan Beulich wrote:
>> On 22.02.2021 15:03, Andrew Cooper wrote:
>>> Hello,
>>>
>>> Staging is now capable of writing out an ABI description when the
>>> appropriate tool (abi-dumper) is available.
>>>
>>> We now have to possible courses of action for ABI checking in builds.
>>>
>>> 1) Publish the ABI descriptions on xenbits, update all downstream test
>>> systems to invoke abi-compliance-checker manually.
>>>
>>> 2) Commit/update the ABI descriptions when RELEASE-$X.$Y.0 is tagged,
>>> update the main build to use abi-compliance-checker when available.
>>>
>>>
>>> Pros/Cons:
>>>
>>> The ABI descriptions claim to be sensitive to toolchain in use.  I don't
>>> know how true this is in practice.
>>>
>>> Publishing on xenbits involves obtaining even more misc artefacts during
>>> the build, which is going to be firm -2 from downstreams.
>>>
>>> Committing the ABI descriptions lets abi checking work in developer
>>> builds (with suitable tools installed).  It also means we get checking
>>> "for free" in Gitlab CI and OSSTest without custom logic.
>>>
>>>
>>> Thoughts on which approach is better?  I'm leaning in favour of option 2
>>> because it allows for consumption by developers and test systems.
>> +1 for option 2, fwiw.
>>
>>> If we do go with route 2, I was thinking of adding a `make check`
>>> hierarchy.  Longer term, this can be used to queue up other unit tests
>>> which can be run from within the build tree.
>> Is there a reason the normal build process can't be made fail in
>> case verification fails? Besides "make check" typically meaning to
>> invoke a functional testsuite rather than (just) some compatibility
>> checking, I'd also be worried of no-one (likely including me) to
>> remember to separately run "make check" at appropriate times.
> 
> As far as RPM is concerned, splitting the two is important, as %build
> and %check are explicitly separate steps.  I have no idea what the deb
> policy/organisation is here.
> 
> Merging some of check into build would be a layering violation, and even
> if we did so, where do you draw the line?

Well, building a shared object that won't load is as bad as building
a shared object that won't work because of violating expected
guarantees. The closest similarity I can think of right away would be
the linker error you ought to get when a to-be-exported symbol can't
be resolved. The line imo would be drawn between things detectable at
build time vs those only detectable by actually using the generated
binaries.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.