ABI check results

Development
1

On Wed, Feb 2, 2011 at 9:12 AM, Konstantin Tokarev annulen@yandex.ru wrote:

Hi all,

I’ve added a page to the wiki with Upstream Tracker ABI check results

http://avogadro.openmolecules.net/wiki/Upstream_Tracker

For convenience I’ve forwarded results using iframe inside of htmlets

Is current git master or 1.0? It looks like master, where (on your
repeated request) we agreed to break ABI. It would be much more useful
to see a report on the 1.0 branch with respect to previous releases.
For master the goal is to maintain API compatibility, but the SO
version will be bumped.

Marcus

2

02.02.2011, 17:24, “Marcus D. Hanwell” mhanwell@gmail.com:

On Wed, Feb 2, 2011 at 9:12 AM, Konstantin Tokarev annulen@yandex.ru; wrote:

Hi all,

I’ve added a page to the wiki with Upstream Tracker ABI check results

http://avogadro.openmolecules.net/wiki/Upstream_Tracker

For convenience I’ve forwarded results using iframe inside of htmlets

Is current git master or 1.0? It looks like master, where (on your
repeated request) we agreed to break ABI.

Right, it’s master.

It would be much more useful
to see a report on the 1.0 branch with respect to previous releases.

I’ve sent a request just now.

For master the goal is to maintain API compatibility, but the SO
version will be bumped.

We can monitor API changes with this tool as well (including newly added methods),
any break will be ABI break too.

–
Regards,
Konstantin

3

2011/2/2 Konstantin Tokarev annulen@yandex.ru:

02.02.2011, 17:24, “Marcus D. Hanwell” mhanwell@gmail.com:

On Wed, Feb 2, 2011 at 9:12 AM, Konstantin Tokarev annulen@yandex.ru; wrote:

Hi all,

I’ve added a page to the wiki with Upstream Tracker ABI check results

http://avogadro.openmolecules.net/wiki/Upstream_Tracker

For convenience I’ve forwarded results using iframe inside of htmlets

Is current git master or 1.0? It looks like master, where (on your
repeated request) we agreed to break ABI.

Right, it’s master.

It would be much more useful
to see a report on the 1.0 branch with respect to previous releases.

I’ve sent a request just now.

For master the goal is to maintain API compatibility, but the SO
version will be bumped.

We can monitor API changes with this tool as well (including newly added methods),
any break will be ABI break too.

I am not that interested in API changes, I am interested in API
breaks. Only some API changes will result in ABI breaks, I spent a
significant amount of time attempting to explain this to you last
year… Read the KDE and Qt ABI wiki pages again if you are
interested.

This tool should help to spot changes in API so that I can manually
inspect them for possible API breakages.

Thanks,

Marcus

4

Only some API changes will result in ABI breaks, I spent a
significant amount of time attempting to explain this to you last
year… Read the KDE and Qt ABI wiki pages again if you are
interested.

I’ve carefully reexamined KDE page. I have not found Qt-specific
instructions, they refer to KDE policy.

I’ve found only one 4 way to break API without ABI breakage (last
two of them will keep source compatibility, so I’m not sure they
qualify as API breaks).

  1. Overload method which was not overloaded in older API
    (will break usage of class method pointers).

  2. Add pure virtual method to exported leaf class.

  1. Change default value of parameter.

  2. Change behavior of existing method (e.g., if I made PluginManager
    not loading plugins if application had not set plugin path explicitly).

So I think it’s more correct to say “Only some API changes will not result in ABI breaks”.

P.S. Unexpectedly found this statement:

“Avoid the use of anonymous namespaces in favor of the static keyword if
possible. A name localized to the compilation unit with static is guaranteed
to have internal linkage. For names declared in anonymous namespaces
the C++ standard unfortunately mandates external linkage. (7.1.1/6, or see
various discussions about this on the gcc mailing lists)”

http://qt.gitorious.org/qt/pages/CodingConventions#Things+to+avoid
in the last paragraph

Also, WebKit seems to have the same policy (static functions are abundant there)

P.P.S. I’m not trying to start a flamewar, just find the truth :slight_smile:
Yep, I realize that meaning of static is too overloaded in C++

–
Regards,
Konstantin

5
  1. Add pure virtual method to exported leaf class.

…which did not have virtual methods before (or ABI breaks)

–
Regards,
Konstantin

6

On Wed, Feb 2, 2011 at 11:04 AM, Konstantin Tokarev annulen@yandex.ru wrote:

Only some API changes will result in ABI breaks, I spent a
significant amount of time attempting to explain this to you last
year… Read the KDE and Qt ABI wiki pages again if you are
interested.

I’ve carefully reexamined KDE page. I have not found Qt-specific
instructions, they refer to KDE policy.

I’ve found only one 4 way to break API without ABI breakage (last
two of them will keep source compatibility, so I’m not sure they
qualify as API breaks).

I don’t really have time for this, but you misunderstood my point…
Many API changes will break ABI, but there are quite a few things you
can change in the API without breaking the ABI. You seem to be
confusing the words break and change.

My point was that we already said we were allowing ABI breaks in
master, but agreed that we would not allow any API breaks. That means
that almost anything listed on that page is irrelevant, but things
like removing classes from libavogadro (which you did and I reverted)
would break the API - code recompiled against a newer Avogadro would
fail to compile and/or link. Understand now?

> > So I think it's more correct to say "Only some API changes will _not_ result in ABI breaks". > Thanks, you basically said the same thing. It would perhaps be more correct to say "some API changes will result in ABI breaks, others will not, you should read up on which are which". Followed up with, the main point of Marcus' earlier response was that for master he is only interested in changes which break the API compatibility as we decided long ago to allow ABI breaks in master.

Is this now clear enough for you? We have gone over this several times
already on and off list.

P.S. Unexpectedly found this statement:

“Avoid the use of anonymous namespaces in favor of the static keyword if
possible. A name localized to the compilation unit with static is guaranteed
to have internal linkage. For names declared in anonymous namespaces
the C++ standard unfortunately mandates external linkage. (7.1.1/6, or see
various discussions about this on the gcc mailing lists)”

http://qt.gitorious.org/qt/pages/CodingConventions#Things+to+avoid
in the last paragraph

Well, you learn something new everyday. I had not spotted that, and
perhaps we should adapt our policy. I will go away and read up on
this.

Also, WebKit seems to have the same policy (static functions are abundant there)

Not really concerned with webkit, but OK. I will leave this thread
here, as I think I have spent far more than I should have on this, and
I am really quite busy today.

Marcus

7

02.02.2011, 19:39, “Marcus D. Hanwell” mhanwell@gmail.com:

My point was that we already said we were allowing ABI breaks in
master, but agreed that we would not allow any API breaks. That means
that almost anything listed on that page is irrelevant, but things
like removing classes from libavogadro (which you did and I reverted)
would break the API - code recompiled against a newer Avogadro would
fail to compile and/or link. Understand now?

I don’t think that binary layout change is technically API break - though such thing
would be immediately spotted by upstream tracker.

I will leave this thread here, as I think I have spent far more than I should have on this, and
I am really quite busy today.

Sorry for spending your time, but I actually did not expect fast answers :slight_smile:

–
Regards,
Konstantin

8

On Wed, Feb 2, 2011 at 11:45 AM, Konstantin Tokarev annulen@yandex.ru wrote:

02.02.2011, 19:39, “Marcus D. Hanwell” mhanwell@gmail.com:

My point was that we already said we were allowing ABI breaks in
master, but agreed that we would not allow any API breaks. That means
that almost anything listed on that page is irrelevant, but things
like removing classes from libavogadro (which you did and I reverted)
would break the API - code recompiled against a newer Avogadro would
fail to compile and/or link. Understand now?

I don’t think that binary layout change is technically API break - though such thing
would be immediately spotted by upstream tracker.

The two are different but related, I was hoping you might come to
appreciate that. I will let you make the rest of this journey (or not)
without me. ABI stability is generally far more restrictive than API
stability, if you look really hard you can probably find a few
exceptions to this though, I am sure.

I will leave this thread here, as I think I have spent far more than I should have on this, and
I am really quite busy today.

Sorry for spending your time, but I actually did not expect fast answers :slight_smile:

Yeah, OK. This is a good reason for code review. I will spot most of
these issues and can just point them out inline.

Marcus

9

It would be much more useful
to see a report on the 1.0 branch with respect to previous releases.

BTW, you can create RC tag, and it will be added to the tracker soon.

Another possibility is to use separate copy of upstream tracker -
underlying software is open source (LGPL). Maybe Kitware is also interested
in such tool?

http://ispras.linuxfoundation.org/index.php/API_Sanity_Autotest
http://ispras.linuxfoundation.org/index.php/ABI_compliance_checker

–
Regards,
Konstantin

10

Fixed - now current (git) points to 1.0, master was excluded

http://avogadro.openmolecules.net/wiki/Upstream_Tracker

–
Regards,
Konstantin