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.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.
OK, so Alex, are you going to have time to do this or should someone at
Kitware do it?
-Bill
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
