John Plocher wrote:
> Garrett D'Amore wrote:
>> If KDE has a way to shield applications underneath from such a binary
>> breakage, then its a different story altogether.
>
> It easily can do that. The key is to realize that "binary compatibility"
> is not a forever thing, or a global thing, but lasts only until a Major
> release of a consolidation is released as part of a larger product.
>
> If KDE were to make this C++ library a standard part of its
> consolidation,
> then KDE could promise to never change it incompatibly unless KDE itself
> were to produce a Major release of KDE.
>
> In the same way as we would not expect or require absolute binary
> compatibility between KDE.old clients and KDE.major.new servers,
> we would not require absolute binary compatibility from its C++
> library.
True. But this would mean integrating the C++ library as a project
private module, right (and so KDE would not directly be exporting any of
this library's interfaces)? The project team has rejected that proposal.
>
>> To put this in comparison, imagine if almost all of the standard C
>> functions were simply *macros* rather than functions, and the macros
>> made references to volatile innards of the C library.
>
> If we did this, our promise would have to be "binary compatibility
> guarenteed only until we changed things incompatibly", at which point
> we would have to up the major version number of ON (and thus SunOS
> and Solaris because of the transitive law of maximal inconvenience...)
Right. The point is, the project as proposed creates just such a mess.
>
> For stuff like libc and core ON, absolute compatibility over eons is
> a no brainer; elsewhere it may easily have less (or even no) value.
I'd argue that a C++ base ABI is almost as critical for C++ as libc is
for C. Certainly if we're going to bless it with some kind of
"Standard" or "Committed" binding (as the case has requested) then
compatibility should have some meaningful value.
>
> All this proves is that binary compatibility isn't a global constant.
This is one of the cases where binary compatibility is *really*
important, though. I don't really care if Gnome breaks compatibility
(though hopefully other people do!) for middleware, but this bit of
piece is potentially a foundation for *all* C++ code. Its just about as
critical for C++ code as libc is for C code. (Yes, you can write
libraries that don't link against the Standard C++ library, and you can
also make C libraries that don't rely on libc. However, the *norm* is
that these baselines are *safe* for building new software upon, and most
libraries can be expected to use them.)
For the record, I've not said that we can't allow for change, or even
incompatible change here. All I've said is that this has to be properly
thought out (with the ramifications for other bits that build upon this
well considered), rather than shoved through while declaring that
compatibility is irrelevant. IMO, such a position would be highly
irresponsible.
We wouldn't just swap out the Solaris kernel and replace it with a Linux
kernel (even as an "option") without careful consideration. Yet, in
many ways, the ramifications of this change are as sweeping for C++
development as a new kernel would be.
-- Garrett
