[cmake-developers] User vs CMake include mismatch handling

[David Cole]

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


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.


David C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101012/3804de04/attachment.html>