On Tuesday 05 October 2010, James Bigler wrote:
On Tue, Oct 5, 2010 at 2:08 PM, Alexander Neundorf neund...@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
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
