Hi !
Sergei Golubchik wrote:
> Hi!
>
> On Aug 26, Joerg Bruehe wrote:
>> Sergei Golubchik wrote:
>>> On Aug 26, Joerg Bruehe wrote:
>
>>> [[...]]
>> 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.
That's a good example.
A storage handler needs to include both "mysql_priv.h" and "plugin.h",
so if a function is moved from the first to the second header this does
not break existing source code (not even binaries).
(Sure the version number needs to be changed, etc, so maybe ".so"
versions don't match and linking fails - that's not my point.)
So it may be important not to change the function prototype by accident
(unless there are good reasons).
And exactly for this I want both ".out" files to exist before any ".pp"
*needs* to be changed (so that "make" doesn't terminate).
I never said this would leave the API/ABI unchanged, the move could be
done freely, or such, all I want is to provide the overall view.
>
> [[...]]
>
>> [[...]]
>>
>> 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.
Sure. I never meant a build (with ABI check) to succeed with any
out-of-date ".pp" file, whether one or more.
>
>> 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.
Sure it is ok to do so, if the developer chooses.
But I do not want this choice to be enforced - the developer should not
be prevented from using the overall view, IMO.
>
> 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.
Because all ".pp" files need to be valid. Agreed.
Regards,
Jörg
--
Joerg Bruehe, MySQL Build Team, joerg@stripped (+49 30) 417 01 487
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
