Update cmake minimum version to 3.10.2 for Ubuntu 18.04

[JonasVautherin]

In MAVSDK, we support cmake 3.10.2 because that's the version coming with Ubuntu 18.04. I do realize that tinyxml2 was updated to more modern cmake features, and therefore I tried here to keep them, but using a fallback for those newer features.

As a consequence, that removes pkg-config for older versions, but anyway those are not currently supported...

I am not completely sure of the consequences of these changes, but my feeling is that they should have no impact for cmake 3.15+, and it makes sense to me to still support Ubuntu 18.04. If you don't want to, I'll just keep that as a patch step in MAVSDK 👍 😊.

This is being tested in MAVSDK's CI here, together with #865

[JonasVautherin]

Actually I added ubuntu-18.04 to the CI to make it clearer why 3.10.2 is used 😊

[leethomason]

@alexreinking Thoughts on this PR?

[alexreinking]

Upgrade CMake, don't downgrade upstreams.

It is ludicrously, amazingly easy to upgrade. I can think of at least four good ways to keep CMake up to date on Ubuntu 18.04 LTS:

1. Add the Kitware APT repo
2. Install via snap
3. Install via pip
4. Download the statically linked binaries and run as a normal user out of the downloads folder.

I oppose this PR. Downgrading CMake makes the code more verbose and harder to maintain. For more on this point:

https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html

[JonasVautherin]

Fair point, though that's a bit of a philosophical argument, and therefore I'd like to share my own preference, too.

Upgrade CMake, don't downgrade upstreams.

Like it or not, Ubuntu is a very popular system. Every two years, they release a new LTS version, LTS meaning "5 years", if I am not mistaking. If one chooses an LTS version, I would argue that they don't do it so that they can add custom APT repos to update packages themselves. On the contrary, it seems to me that they want to trust the distro maintainers with the packages they provide. Otherwise why not just updating or going with a distro with rolling releases? If you choose to support Ubuntu, it feels reasonable to me to say that in May 2021, the last active LTS is 18.04, and therefore support it.

Here, what I understand you are saying is: "it's fine if you don't want rolling releases, but in order to use my library, I will show you how to make updates manually anyway". Which somehow means that you don't find it fine to not have rolling release, doesn't it? 🤔

In my opinion, either I support Ubuntu 18.04, or I don't. But I personally don't call it "Ubuntu 18.04 support" if it comes with a list of packages you need to update.

Downgrading CMake makes the code more verbose and harder to maintain.

Here I could argue that for Ubuntu 18.04 support, CMake should not have been upgraded 🙂. I did put quite some care into checking what was not compatible with CMake 3.10.2, though, and clearly marked it in the code so that it can easily be removed when CMake gets updated again (I even went the trouble to check which version introduced the new feature). Those are exactly 3 places in the code, and they do not feel super hard to maintain (to me).

I oppose this PR.

Again, that's perfectly fair, this is not my repo. If the PR is refused, I will stay on an older version of tinyxml2 (e.g. the one that comes with Ubuntu 18.04, together with CMake 3.10.2 🙈) or I will just provide a patch in my project, but I won't tell users to upgrade their LTS system until we drop support for Ubuntu 18.04.

[JonasVautherin]

@alexreinking: Just read https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html, it's interesting, and I'm looking forward to reading the next posts about the modern cmake features. It's always nice to have modern tutorials out there, since as you mention there are many outdated ones as well 😊.

This said, I maintain my opinion. I believe that your post makes a lot of good points, but I also believe that you miss the distro philosophy (seems like you run Windows, which would explain it). Let me try to elaborate, so that you can explain to me why I am wrong:

First, your argument would not hold for any library on the system. "Use the latest OpenSSL" or "Use the latest X" will be an issue if you hope to get your project as an "official" package in a distro. If Ubuntu 18.04 comes with a version of OpenSSL, your project should be compatible with it, otherwise it will become a problem to install it on that system, right?

Assuming that we agree regarding the system libraries, let's consider CMake itself. Can you guarantee that CMake does not depend on anything on the system? Aren't there CMake modules used by find_package installed on the system? Moreover, doesn't CMake use defaults when it comes to system paths? Couldn't we imagine a distro that patches the CMake it distributes so that it works on that very system? That's what maintainers do: they try to guarantee that what they distribute works on the system. Whatever you install on top is your own responsibility.

And last, but not least: does it make sense to you to ask a distribution to use different versions of CMake to build packages for that distro? Should the maintainers of Ubuntu 18.04 make sure that their system downloads the right version of CMake for your project? Chances are, in my opinion, that they won't build your project for their distro if your project is too modern for their CMake.

So no, I don't think that taking any version of CMake older than the one coming with Ubuntu 20.04 is "plain masochism", as you say. I am not completely sure why you chose 20.04, but I'm guessing that you chose Ubuntu because of its popularity. And in that case, it would make sense to me to consider the oldest active LTS version, which is 18.04, coming with CMake 3.10.2 👍.

[alexreinking]

sudo apt remove cmake && sudo apt install snap && snap install cmake

Installs CMake 3.20.2 on Ubuntu 16.04+

[alexreinking]

Like it or not, Ubuntu is a very popular system.

I do like Ubuntu. I run Ubuntu 20.04 LTS as my main development system.

if I am not mistaking. If one chooses an LTS version, I would argue that they don't do it so that they can add custom APT repos to update packages themselves. On the contrary, it seems to me that they want to trust the distro maintainers with the packages they provide. Otherwise why not just updating or going with a distro with rolling releases? If you choose to support Ubuntu, it feels reasonable to me to say that in May 2021, the last active LTS is 18.04, and therefore support it.

You are mistaken. Ubuntu has a long history of making large user interface changes and experimenting with the system stack off-LTS. I use 20.04 LTS because I want my OS experience to remain stable, for my drivers to work, and so on. I keep my developer tools up to date because it's trivial.

In my opinion, either I support Ubuntu 18.04, or I don't. But I personally don't call it "Ubuntu 18.04 support" if it comes with a list of packages you need to update. Here I could argue that for Ubuntu 18.04 support, CMake should not have been upgraded 🙂.

Ubuntu 16.04 is supported if you install CMake through Snap, which is supported by Canonical.

I did put quite some care into checking what was not compatible with CMake 3.10.2, though, and clearly marked it in the code so that it can easily be removed when CMake gets updated again (I even went the trouble to check which version introduced the new feature). Those are exactly 3 places in the code, and they do not feel super hard to maintain (to me).

All the time spent downgrading upstream CMake projects, adding corner cases and maintenance burden would be better spent teaching people to run one command to keep CMake permanently up to date.

I also believe that you miss the distro philosophy (seems like you run Windows, which would explain it). Let me try to elaborate, so that you can explain to me why I am wrong:

Nope. I am primarily a Linux user. I do partly maintain the Windows version of Halide, so I dual boot.

First, your argument would not hold for any library on the system. "Use the latest OpenSSL" or "Use the latest X" will be an issue if you hope to get your project as an "official" package in a distro. If Ubuntu 18.04 comes with a version of OpenSSL, your project should be compatible with it, otherwise it will become a problem to install it on that system, right?

CMake is not a library.

Assuming that we agree regarding the system libraries, let's consider CMake itself. Can you guarantee that CMake does not depend on anything on the system?

Yes. CMake depends only on glibc6, which has been ABI stable since 1997.

Aren't there CMake modules used by find_package installed on the system?

No. There are CMake modules used by find_package installed relative to the CMake executable, which is why it can run out of the un-tarred archive in your downloads folder.

Moreover, doesn't CMake use defaults when it comes to system paths?

It detects these from querying the toolchain.

Couldn't we imagine a distro that patches the CMake it distributes so that it works on that very system? That's what maintainers do: they try to guarantee that what they distribute works on the system. Whatever you install on top is your own responsibility.

We could imagine such a distro, but I am not aware of any. Ubuntu's CMake is vanilla AFAICT.

And last, but not least: does it make sense to you to ask a distribution to use different versions of CMake to build packages for that distro? Should the maintainers of Ubuntu 18.04 make sure that their system downloads the right version of CMake for your project? Chances are, in my opinion, that they won't build your project for their distro if your project is too modern for their CMake.

Fortunately, this is not an issue for tinyxml2 because it can be compiled with a single GCC command, as it is a single source file.

For a larger project, I would sooner not ask anything of the Ubuntu maintainers and provide a first-party APT repo, Snap package, Pip package, or suggest to the maintainers that they may build CMake from source, bootstrapped with Ubuntu 18.04's own CMake 3.10, than shackle my project across all platforms and users (not just those on a stubborn distro) to an old CMake version.

So no, I don't think that taking any version of CMake older than the one coming with Ubuntu 20.04 is "plain masochism", as you say. I am not completely sure why you chose 20.04, but I'm guessing that you chose Ubuntu because of its popularity. And in that case, it would make sense to me to consider the oldest active LTS version, which is 18.04, coming with CMake 3.10.2 👍.

I chose it because it's what I'm running. I also didn't advocate for using 3.16 (the version on Ubuntu 20.04), I suggested it as a compromise.

but I won't tell users to upgrade their LTS system until we drop support for Ubuntu 18.04.

You should tell your users to install CMake from snap.

[JonasVautherin]

Okay, I think we just won't agree. It's not in my philosophy to impose my preferences on others, as I don't know their use-case and security constraints.

The only choice I make is the oldest version of a system I support, and in my case it's Ubuntu 18.04. We provide a superbuild scheme for users who want to compile the deps from sources, and there we will use this patch on our end. For those who don't want the superbuild, it's their responsibility to get the deps on their system the way they want it.

Thanks for reviewing.