[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Tuesday 05 October 2010, James Bigler wrote:
> On Tue, Oct 5, 2010 at 2:08 PM, Alexander Neundorf <neundorf at kde.org> wrote:
...
> > The current behaviour is really like running an executable with a shared
> > library LD_PRELOADED, and hoping that the LD_PRELOADED libs will always
> > be work as the correct one would.
> >
> > Alex
>
> This patch breaks backward compatibility, because it changes the include
> order.

I am aware that it can potentially break builds.
But, it only breaks compatibility where cmake *hopes* that nobody else breaks 
it instead of making sure that it gets what it expects.
Also I assume that there are very rare, maybe no projects which rely on this 
very special behaviour.
At least for kdelibs it works.
Will check the other KDE modules and what we have at work tomorrow.

> Just like hoping that no one would want to modify the existing set of
> macros in this way is like assuming that no one will make a copy of a built

You still can override them and create your own copies of cmake-supplied 
modules and use them, no change there. It only changes something for a module 
shipped with cmake which tries to include another module shipped with cmake.
In this case the patch ensures that the including module also gets the module 
included it expects.

IOW, it makes cmake 2.8.3 NOT break the build of applications using installed 
KDE 4.5.[01] kdelibs.

> in macro which will not work in a future version of cmake where the macro's
> api changes.
>
> Why can't you create a new version of the FSA macro in question?  This is
> what is typically done to maintain backward compatibility with binary
> libraries.

Alex