[cmake-developers] User vs CMake include mismatch handling

[Brad King]

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_CURRENT_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.

> macro with a new name ... which we then have to maintain forever

It's not too bad.  The new name has the new API.  The original FPHSA
module can just include the new one and forward calls appropriately.
Any call to the original FPHSA will either go through the CMake version
of it and forward to FPHSA2 or go through a project-overridden one.
Any call to the FPHSA2 will either go through the CMake version or
through one overridden by a project aware of the new API.

This isn't perfect but it is 100% compatible with current project
releases and will get us through this CMake rc cycle safely.  Future
enhancements to FPHSA2 may need yet another new module, but I think
that is in the nature of this particular function.

-Brad