Joerg Thanks again for this reply. I really appreciate you reply inspite
of the cluster work you had.
Joerg Bruehe wrote:
> 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).
*This move does not show a normal situation at all*.
*This is not like a c file where you move a function from one included
header to another*
In a JDBC driver you have Connection and Statement. So you do a
import java.sql.Connection
import java.sql.Statement
what you are saying is equvivalent to saying I will move a function from
Connection to Statement and then call it a valid move.
How can that be so?
Connection is a different entity that encapsulates the essence of a JDBC
Connection
A statement is different in the same sense.
A move from Connection to Statement cannot be justified that way
> (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.
This move cannot be done freely. You cannot move functions between two
semantically different API's.
>
>>
>> [[...]]
>>
>>> [[...]]
>>>
>>> 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.
If the developer is doing things correctly he would not need this
overall view. I am still humbly saying that this move is not valid
at all. He does not need this overall view at any point of his work.
>
>>
>> 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
>
