[cmake-developers] User vs CMake include mismatch handling

[David Cole]

On Tue, Oct 5, 2010 at 4:48 PM, Alexander Neundorf <neundorf at kde.org> wrote:

> 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
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>

Another solution to this whole fiasco to consider... rather than what we
have now, or one of your two proposals (the CMAKE_CURRENT_LIST_DIR or the
backwards-compatibility breakage) ... is as follows:

Revert the FindPackageHandleStandardArgs.cmake to how it used to be. Add a
new module with the new functionality (and a new name, perhaps
FindPackageHandleStandardArguments, just to make FPHSA even longer... :-) ).
Then include the new module, instead of the old one in built-in files in
CMake.

This is still clean from both CMake and KDE points of view, does not break
backwards compatibility, and solves the problem. At least in this instance.

Now, it would still be possible to introduce this problem again, in another
case, but consider the whole cause of this in the first place: we added new
stuff to an existing function, and then started using it, not considering
that it itself was the first break in backwards compatibility. Clearly, the
new FPHSA.cmake module should still work with existing non-FPHSA modules in
KDE. Since it does not, we've broken backwards compatibility already. We
should have seen this problem earlier. I think we need a "contract" test for
kdelibs and some KDE apps to avoid this happening again moving forward.


(just my) 2 cents,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101005/2fd620d9/attachment.html>