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@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers