[CMake] CMake 2.8.0 RC 1 ready for testing!

[Michael Pyne]

On Tuesday 29 September 2009 16:05:38 Matt Williams wrote:
> 2009/9/29 Alexander Neundorf <a.neundorf-work at gmx.net>:
> > On Tuesday 29 September 2009, Pau Garcia i Quiles wrote:
> >> On Tue, Sep 29, 2009 at 8:16 PM, Alexander Neundorf
> >>
> >> <a.neundorf-work at gmx.net> wrote:
> >> > I guess we will with it, because I don't really see a difference
> >> > between source compatibility for C++ files and for CMake files. In
> >> > both cases, if it's broken, the package will not compile.
> >>
> >> Do we promise source compatibility for C++ files? I thought we only
> >> promised *binary* compatibility through KDE 4.x but not *source*.
> >
> > Didn't really find it for KDE now (except here:
> > http://en.wikipedia.org/wiki/KDE), but for Qt:
> > http://qt.gitorious.org/qt/pages/CodingConventions#Binary+and+Source+Comp
> >atibility
> 
> It's mentioned at
> http://techbase.kde.org/Policies/SVN_Commit_Policy#Code_review_by_other_dev
> elopers and http://techbase.kde.org/Policies/CMake_and_Source_Compatibility
>  (written by you :D)
> 
> However, (I'm no expert, but) I can't think of a time where you could
> break source compatibility while keeping binary compatibility. Or at
> least it's strange to require one but not the other.

Easy.

You compile KApp 4.0 on kdelibs 4.0.

2 years later you upgrade your distro and now kdelibs is a shiny 4.3 (but 
you're still happily running KApp 4.0).

You decide to play with new g++ features and recompile KApp 4.0 against 
kdelibs 4.3, only to discover that now it won't build at all!

This is breaking source compatibility while maintaining binary compatibility.

Regards,
 - Michael Pyne
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090929/43742b7a/attachment.sig