[cmake-developers] User vs CMake include mismatch handling

[Bill Hoffman]

On 10/12/2010 6:01 PM, Marcus D. Hanwell wrote:
> On Tuesday 12 October 2010 17:27:31 David Cole wrote:
>> On Tue, Oct 12, 2010 at 5:21 PM, Brad King<brad.king at kitware.com>  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.
>>>
>>>> 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.
>>>
>> I really think a second function is the way to go here. It is the least
>> risky and maintains full compatibility with existing module overrides. It
>> does not have to be named FPHSA2 (I am not a big fan of "2" named
>> functions...) but I do think it needs to be a newly-named function, and
>> keep the old function as is.
>>
>> We can come up with better solutions moving forward, but for now, to keep
>> *everything* working well without breaking anything *else*... I think a
>> second function is our only realistic option.
>>
> I like the malloc analogy, and think it holds here. We do have a certain
> responsibility to maintain API compatibility, and having a new function seems
> like the best way to achieve that for the release. Going forward, versioned
> include files, or preference towards local files might be the way to go.
>

OK, so Alex, are you going to have time to do this or should someone at 
Kitware do it?

-Bill