Hi Sergei, all !
Sergei Golubchik wrote:
> Hi!
>
> On Aug 26, Joerg Bruehe wrote:
>>>>> [[...]]
>>>>>
>> This is the point where you do not convince me.
>>
>> I do not claim such a move would be acceptable in general, not at all.
>> However, I expect sometimes (rare !) there will be such cases.
>
> 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.
Yes, that was (and still is) my assumption.
I do not claim this would make a move "acceptable", just "possible".
>
> 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" ?
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" ?
You think we currently don't need it - are you sure this won't change ?
>
>>>> Above, you write that moving a declaration "from 1.h to 2.h it is
>>>> not one sin, it is two".
>>>> Assuming that both header files must be included (maybe: they are
>>>> both included by a common, mandatory .h file), I do not necessarily
>>>> see that as a sin, it may be a proper cleanup / restructuring.
>>> True, but it still qualifies as a change not approved by the storage
>>> engine API team.
>> Of course it would need such an approval, and maybe it won't get it.
>> 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.
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.
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
