[cmake-developers] User vs CMake include mismatch handling

[Eric Noulard]

2010/10/12 Alexander Neundorf <neundorf at kde.org>:
> On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
>> 2010/10/12 Alexander Neundorf <neundorf at kde.org>
>
>> It has its own copy of FindPackageHandleStandardArgs.cmake, which is used
>> in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu),
>> but is C++/Qt based itself. I was more thinking of all the other packages
>> out there that may have done similar, and the fact that we should avoid
>> breaking their builds with a new CMake release.
>
> Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and
> KDE4 is not the only project which breaks together with current cmake 2.8.3.
>
> This reduces the number of acceptable solutions I think.
>
> Remaining are as far as I see:
>
> -set new policy CMP0017 to NEW by default
> Projects with an exotic setup may break, but that's probably better than
> breaking all KDE 4.5.0/1 builds. One could also argue that these projects
> relied on internal implementation details of cmake. As a pro, I think this
> behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense,
> since we have that dependency but currently it's not enforced.
>
> -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also
> to CMakeParseArguments.cmake and FindPackageMessage.cmake
> IMO not a solution, just a quick fix for the moment, because we have to
> maintain this forever in the future and basically we need to check *all*
> other include()s in CMAKE_ROOT.
>
> -rename the enhanced FPHSA to FPHSA2
> Worse than above, since this doesn't give any guarantee that the same does not
> happen again in the next cmake release with the renamed function.
>
>
> Did I miss anything ?

Yes there is another not-so-pleasant option:

- revert CMake's FPHSA changes in order to stay compatible with 2.8.2 one
  and KDE and other currently "annoying project" w.r.t. FPHSA
  The "incompatible" improvement of FPHSA may be postponed to 2.8.4, and
  we will have to design a "good" solution and warn all project about
"bad habits"
  before 2.8.4.

Suggesting this I'm don't even know how much impact it has on
CMake-shipped modules,
i.e. how many modules do currently use the new FPHSA?

If the idea is plain stupid just forget my mail, I genuine want to be
positive on this
issue not trying to shot on others efforts (Alex in this case) to improve CMake.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org