[CMake] Advice on converting legacy project to modern CMake

[Robert Maynard]

> Which leads to a question I have for the Kitware types here.  What
should I suggest to my Linux enterprise distribution users? Can they
simply download and use the latest Linux binary version of CMake that
is distributed by Kitware or are there library version
incompatibilities that make that option non-viable? Alternatively, if
such users want to build modern CMake for themselves can they do that
or do system library incompatibilities stop them in that case as well?

The official CMake  binaries are built using a static libstdc++ and
static glibc so they should be able to work on any x86_64 linux
machine.

On Mon, Aug 7, 2017 at 4:53 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2017-08-07 11:35-0000 Björn Blissing wrote:
>
>> 1. Which version if CMake should I target? I.e. Which version should
>
> I require in my cmake_minimum_required() statement?
>
> I would suggest either
>
> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
>
> or
>
> cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)
>
> depending on whether the Cygwin platform (currently only making
> 3.6.2 available) is important to your users or not.
>
> Cygwin is important to PLplot so we recently adopted 3.6.2 as the
> minimum version choice as the compromise between two goals:
>
> (1) We wanted to maximize the version of policies
> (which are set by cmake_minimum_required) since the latest
> version of policies typically make a lot of sense to us
> in terms of eliminating subtle build-system bugs.
>
> (2) We wanted to minimize the minimum version to maximize the
> percentage of our users who will have that minimum version or higher
> available from the official binary CMake version that is supplied by
> their software distribution.
>
> 3.6.2 currently satisfies goal (1) reasonably well because it is not too far
> behind the latest version 3.9.0 in terms of policy.
>
> 3.6.2 also satisfies goal (2) reasonably well.  The major exception
> here is the so-called Linux "enterprise-class" distributions who go
> out of their way to **only** support old versions of Linux software
> because their customers somehow feel more comfortable with that.  For
> example, as far as I can tell from google searches, it looks like
> RedHat Linux Enterprise versions still only support CMake-2.
>
> Which leads to a question I have for the Kitware types here.  What
> should I suggest to my Linux enterprise distribution users? Can they
> simply download and use the latest Linux binary version of CMake that
> is distributed by Kitware or are there library version
> incompatibilities that make that option non-viable? Alternatively, if
> such users want to build modern CMake for themselves can they do that
> or do system library incompatibilities stop them in that case as well?
>
> If we ignore the "enterprise-class" users, then Debian stable supports
> 3.7.2.  Debian tends to be a bit of a late adopter so as far as I know
> every other non-enterprise Linux distribution and the various *BSD
> distributions supports that version of CMake or higher. And I know
> that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions
> (Homebrew, MacPorts, and Fink).  So I plan to bump the minimum version
> we support to 3.7.2 as soon as Cygwin (currently only supporting
> 3.6.2) falls into line with the rest.
>
> I haven't mentioned the Windows MSVC platform here yet which is also
> important to us.  But those users are given no official choice of
> CMake as a binary download so they likely take another viable choice
> which is to download, install, and use a Kitware binary version of
> CMake for Windows, and as far as I know all released versions of
> CMake-3 (as well as CMake-2) are available that way.
>
> In any case, for whatever minimum version of CMake you adopt, you
> should test your build system for that version as well as at least the
> latest CMake version.
>
> 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