On Wed, Feb 2, 2011 at 11:04 AM, Konstantin Tokarev email@example.com 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
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)”
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
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.