[cmake-developers] User vs CMake include mismatch handling

Alan W. Irwin irwin at beluga.phys.uvic.ca
Tue Oct 12 14:28:26 EDT 2010


On 2010-10-12 19:38+0200 Alexander Neundorf wrote:

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

To me your argument for the CMP0017 policy to enforce the rule that
"include()s from CMAKE_ROOT first check in
CMAKE_ROOT" makes a lot of sense.

However, can you explain further your comment above that "Projects
with an exotic setup may break"....  What exactly do you mean by that?

I thought policies were set up to assure a high degree of backwards
compatibility, i.e., in this case CMP0017 will not be used unless a
project deliberately bumped the CMake minimum version number they were
using.

However, if all you are saying is that projects may break if they bump
their CMake minimum version number, then that is a given and
completely acceptable. For example, PLplot currently uses

cmake_minimum_required(VERSION 2.6.4 FATAL_ERROR)

and that works well for any CMake version between 2.6.4 and 2.8.2.

However, when I bump that minimum version to 2.8.3 (or whatever) I expect
some breakage that will have to be addressed because of the different
policies that will be used that are backwards-incompatible with the
policies of 2.6.4 that are previous build system was using.

I assume in the KDE4 case you will be using

cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)

because you absolutely need CMP0017.  I believe most projects
(including PLplot) will eventually need that policy as well because
there is a tendency to copy and modify CMake find modules to the
project's special needs for any mature project.  Thus, I assume PLplot
will need CMP0017 in the future, but when that occurs I will bump our
minimum version to a high enough value so we are assured of having
that policy.

Am I missing something?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the cmake-developers mailing list