Re: WL#4380 ABI check: Implementation details

[Sergei Golubchik]

Hi!

On Aug 26, Joerg Bruehe wrote:
> Sergei Golubchik wrote:
>> On Aug 26, Joerg Bruehe wrote:

>> You seem to assume that one source (.c or .cc) file can include two
>> (monitored by check_abi rule) .h files, and in that case it would be
>> acceptable to move a definition from one to another.
>
>> But it's never the case. We have one .h file per API. plugin.h - it's
>> plugin API, mysql.h - it's client-server API, mysql_priv.h - it's for
>> storage engines. Moving a definition from one API to another is never
>> one atomic action. It's two, as VN has explained above.
>
> I haven't worked in that area, so maybe my question is silly: As we
> want to support storage engines as plugins, doesn't that mean their
> sources have to include both "mysql_priv.h" and "plugin.h" ?

Correct, it does. But these correspond to different API's. Moving
something (e.g. a function prototype) from mysql_priv.h to plugin.h,
means that this function was *added* to plugin API. This fact alone
means that plugin API version should be increased. And it's unrelated to
what has happened to mysql_priv.h.

> And even if that isn't so just now, don't you think it quite possible
> that we add header files for specific functional areas, which plugin
> sources need to include in addition to "plugin.h" ?

Yes, we're doing that. But see above.

>>> All I say is that the API team must be given all differences
>>> simultaneously, not piecemeal.
>> And it will. API team will see a commit email - which changes all
>> affected .pp files.  Assuming that a developer ensures that his tree
>> builds before committing, of course.
>
> It seems my assumption of the workflow differs from yours:
>
> With the current approach, "make" will terminate a build attempt if one 
> ".pp" file differs from what is generated from current header files.
> So in order to proceed to the next one, the first ".pp" file needs to be 
> adapted to current header contents.

Yes. But a commit should only happen when all .pp files are updated.

> What I would like to see is that one "make" run generates several
> ".pp-new" (or whatever the name may be) files, so that these can be
> compared against the (old) ".pp" files.
>
> For such a major operation as an API change (or placement change that
> doesn't affect the ABI), I simply prefer the simultaneous existence of
> ".pp" and ".pp-new" which can then be compared by the tool of choice,
> not only as the diff output in a commit mail.

There will be .pp and .out files, which can be compared by the tool of
choice. The fact that make fails on the first mismatch means that
developer will need to work on changes filewise, or, rather, API-wise.
Because "API" is a reasonably independent unit, it's ok to work on
changes API-wise, not all at once.

But in the commit mail - which is what others, not the developer who has
caused the change - all changes to the APIs will be seen at once.

Regards / Mit vielen Grüßen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Häring