[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Tuesday 12 October 2010, Brad King wrote:
> On 10/12/2010 03:32 PM, Alexander Neundorf wrote:
> > On Tuesday 12 October 2010, Bill Hoffman wrote:
> >> Anyway, in the short term, we are going to go with FPHSA2, Alex do you
> >> have time to do that?
> >
> > FPHSA2 would have been my last choice.
> >
> > In staging there is already the branch AddCMAKE_CURRENT_LIST_DIR:
> > http://cmake.org/gitweb?p=stage/cmake.git;a=log;h=refs/heads/AddCMAKE_CUR
> >RENT_LIST_DIR
> >
> > where I implemented the option with the hardcoded paths:
>
> The original FPHSA floated around outside of CMake in many projects
> before it was distributed with CMake.  It is a long-established API
> that has been re-implemented (via copying) in many projects.  Therefore
> it is too late to change.  See James Bigler's comment earlier in this
> thread about ABI compatibility approaches.  No one proposes changing
> the ABI of "malloc" in C because many custom allocation libraries
> override it at link time.
>
> Currently projects have the option to override it with CMAKE_MODULE_PATH
> to providing a module with the same API but a tweaked implementation.
> With the CURRENT_LIST_DIR approach that option goes away, and any
> project that does it already will break.

Yes, because this option is what makes cmake break KDE currently. This is the 
problem, this is what must be changed.

Nothing breaks with the CURRENT_LIST_DIR, since this only applies to the 
modules shipped with cmake, so those get what they expect.
The modules shipped with the project still get their own FPHSA.cmake.
I can't think of a constellation which could break.

Otherwise this means that no matter what new features we add to any of cmake's 
modules, we cannot use any of them in any other module.
Do we want that ?


Alex