[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Tuesday 12 October 2010, David Cole wrote:
> On Tue, Oct 12, 2010 at 5:21 PM, Brad King <brad.king at kitware.com> wrote:

...
> > 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.

No, it's not.
Using the full path (as already _completely done_ in the 
AddCMAKE_CURRENT_LIST_DIR branch) is 100% safe now and in future cmake 
releases.
Adding FPHSA2.cmake now in 2.8.3 is safe now, but not as soon as new features 
are added to it in 2.8.4 or later versions.
Projects will have copies of it and it can break just the same way then.

What am I missing here ?
Where is the risk (or any problem) when using the full path ?
I don't understand the argumentation.


FYI, kdelibs 4.5.2 (released 2 weeks ago) has the full-featured FPHSA.cmake, 
so this one will be compatible with 2.8.3, but I think no matter what we 
decide for now, 4.5.2 could be ignored if it stays the only release which may 
have some oddity.

Alex