Hi Nils:
According to "git log" you were the author of the first commit that
referred to CMP0054 so I wanted to publicly thank you and others that
helped you with CMP0054 for the very nice way that is implemented in
practice for developers of CMake-based build systems like me.
Note the PLplot CMake minimum version and corresponding uniform policy
is 3.0.2. We adopt that version to make it easier to build PLplot on
virtually all modern Linux distributions including Debian stable
(which currently only packages 3.0.2). I do have plans in 5 months or
so (likely coinciding fairly closely with when a new Debian stable is
released that will package at least CMake-3.7.0) to bump our minimum
CMake version and uniform policy to at least 3.7.x. But for now we
will be sticking with a policy that conforms to 3.0.2 because of this
modern Linux packaging constraint limiting what versions of cmake are
readily available to Linux users who do not want to have to build
CMake in order to build PLplot.
I now want to move to the issue where the design of CMP0054 saved the
day for me.
The PLplot build system had the following "innocuous" if statement in
one of its heavily used functions:
if(BINDING STREQUAL "c")
That CMake logic has worked well for years in the obvious way
(treating "c" as a simple string) because there was no CMake variable
named c in our build system that would nameclash with that string.
But apparently 4.7.0 does define such a variable and that nameclash
with the "c" string (with CMP0054 OLD behaviour allowing that c
variable to be dereferenced) caused a major issue for that version of
CMake. But because of the nice way that CMP0054 is implemented, CMake
immediately warned about this nameclash when running CMake-3.7.0, and
I was able to temporarily workaround the issue by replacing the above
if statement by
if("X${BINDING}X" STREQUAL "XcX")
(since there is evidentally no variable named XcX to nameclash with
that string). Of course, once we are able to bump our minimum version
to a modern version of CMake like 3.7.0 that allows us to use the much
more logical NEW form of CMP0054 that eliminates the possibility of
such nameclashes, and that vastly preferred policy will allow me to
revert the above workaround necessary for CMP0054 OLD.
In sum, I wanted to acknowledge the forward thinking of everybody that
worked on CMP0054 since that nice implementation saved my ass today
when one of our users who had good success with the PLplot build for
3.6.x reported major PLplot build-system trouble with CMake-3.7.0.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
