Insufficient platform headers are now published for external driver projects

[Kevin DuBois]

Insufficient platform headers are now published for external driver projects to use.

[Daniel van Vugt (vanvugt)]

I get your point. And we will need to re-expose some platform headers.

However while no one is using those headers we're using that as a reasonable excuse to say "nobody's use of the platform ABI has been broken by this header change".

So I think yes, carry on with exposing headers as required. But this is not a bug.

[Daniel van Vugt (vanvugt)]

Reworded into a new form such that it is a definitely bug. Although not a high priority one.

[Kevin DuBois (kdub)]

It is a concern that the platform is now internal and external driver projects can't make use of them.

The bug was filed with a different concern.
The platform and common ABI's are captured by src/common/symbols.map and src/platform/symbols.map. The checksum script, whose purpose is to notify us when the ABI's change, does not reflect the symbols in those map files.

It is possible to run the abi-detecting script after changing the ABI of platform/common, and see a success.

[Daniel van Vugt (vanvugt)]

Unfortunately symbols.map can't capture the full ABI description. Such a list of symbols misses potential subtle ABI breaks such as structure and class member changes. That's why you always need to track the headers to get the full picture.

I'm not a big fan of symbols.map but am not opposing it either, while it doesn't get too much in the way. I know symbols.map is inaccurate right now, and very hard to make accurate while we're changing things frequently. It also has the unfortunate side-effect of bloating our tests (as they can no longer link to the real DSOs the tests need a whole second copy of each library).

[Robert Carr (robertcarr)]

Discussing the publishing of BufferWriter headers in touchspot renderable:

18:56 < racarr> I think
18:56 < racarr> all the files that aren't already in src/ have to be
18:56 < racarr> public, because
18:57 < racarr> third party graphics platforms have to implement bufferwriter
18:57 -!- Ursinha is now known as Ursinha-afk
18:57 * kdub tried that argument for my MP, but it got routed
18:57 < racarr> wait really
18:57 < racarr> hmm
18:58 < racarr> on the basis that, still, no one is using them yet?
18:58 < kdub> yeah :( https://code.launchpad.net/~kdub/mir/unpack-buffer/+merge/232617
18:59 < kdub> the PlatformIpcOperations interface should be public because no one can implement a platform without them,
              but I guess we have a bug for it now
18:59 < kdub> https://bugs.launchpad.net/mir/+bug/1367435
19:02 < racarr> hmm
19:02 < racarr> I think given the dynamics of
19:03 < racarr> the driver author relationship
19:03 < racarr> we should be more liberal in publishing the platform headers
19:03 < racarr> because the turn around time from
19:03 < racarr> us to them if they had to ask for something
19:03 < racarr> is probably like a month

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.10.0

[Kevin DuBois (kdub)]

Moved back to confirmed. The fix committed in lp:~kdub/mir/no-mirtestdraw addressed part of what constitutes this bug, but does not resolve it completely.

[Michał Sawicz (saviq)]

Syncing task from Mir.