On Tuesday 12 October 2010 17:27:31 David Cole wrote: > On Tue, Oct 12, 2010 at 5:21 PM, Brad King <brad.k...@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.
Marcus _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
