Upgrade CMake

[MikeGitb]

There are a few updates I'd like to make to the cmake files, in order to make it easier for the user (and or a package management system) to control the cinder build via typical cmake configuration options. Two examples being the control of the used c++ standard for which CMAKE provides the CMAKE_CXX_STANDARD variable since cmake 3.1 or the hardcoded usage of MT (#2116)

I think that would also be a good time to upgrade the minimal required cmake version, as 2.8 is really old and a lot of things have become easier since then.

I wanted to ask, what an acceptable baseline would be. To give a short overview:
VS2019 currently ships with 3.15, Ubuntu 18.04 with cmake 3.10, Ubuntu16.04 with 3.5. Travis uses 3.12. I have no idea about macos, but generally it is very easy to install a newer version of cmake on any system.

Depending on whether Ubuntu 16.04 is still a common target, I'd recommend 3.5 or 3.10 (among other things, cmake 3.8 adds the cxx_std_14 / 17 target properties which are "nice to have" but not critical).

[alias-r-cummins]

I can tell you Android NDK uses 3.10.2, so no objections on that side.

[kino-dome]

This could definitely be a plus.

[MikeGitb]

@andrewfb , @richardeakin: Ok, so, would 3.10 be fine for you?

[tmtmazum]

Is it strictly necessary to change the CMAKE_MINIMUM_VERSION in order to start using the newer features?

You could add a cmake version guard such as this around the use of the optional features:

    if( ${CMAKE_VERSION} VERSION_GREATER "3.8.2" )
        target_compile_features( cinder PRIVATE cxx_std_17)
    endif()

This would allow use of the newer features for those who have the latest cmake, without breaking the build for folks who have older cmake.

Otherwise there would always be a lag behind cmake features - i.e. if you settle on 3.10, then you're unable to use any features newer than that.

[MikeGitb]

For one, I see little use in using the new features if I have to keep the old code around - just makes the code harder to understand and maintain. Second cmake_minimum_required not only checks the cmake version it also makes sure that newer versions behave as close as possible to the minimum cmake version specified by setting all kinds of policies.

In turn, newer cmake versions start to spew out warnings when cmake_minimum_required is too old and hence is forced to behave in a way that might be suprising to the user.

In short: I don't think there is much to be gained by selectively using new cmake features on the one hand, but trying to stay compatible with extremely old versions of cmake on the other hand, if the end goal is simply to build cinder with a consistent set of options.

[tmtmazum]

Makes sense, thanks for the clarification!

[alias-r-cummins]

Can we establish what the actual minimum version we need to support is going to be? I would suggest dropping support for older versions we are unlikely to need to support. Considering most people are building with either Clang or VCC, there's not that many legacy use cases.

[MikeGitb]

You won't get any arguments from me. I've always been an early adopter. Also, I'd guess that once such a PR would actually get merged (and appear in a release version of cinder), we are easily ahead 3 versions of cmake compared to what was recent when I opened this issue.
But I'm not really a community member and only use cinder on and off in small private projects. So I don't really have any stake in this and hence didn't want to push for this too hard.

[alias-r-cummins]

Well, for me, as I'm trying to modernize the Android side of things, it would certainly make my job easier if we settled on 3.10 or thereabouts. Ideally it should be possible to build it out of the box with Android Studio NDK, generally messing about with CMake versions is the path to suffering.

[PetrosKataras]

My two cents would be to consider CMake 3.10.2 as the minimum which is the default for Ubuntu 18.04. I don't really see a problem with this and even if an older version is required in some edge cases ( e.g SBC's ), CMake can be installed pretty easily from source or through a package manager.

[andrewfb]

I do agree it's probably not the end of the world if certain platforms require building CMake from source, but it's probably worth avoiding that if we can. Here's what I believe are the baselines:

• Raspbian Buster: v3.13.4
• Ubuntu 16.04: v3.5.1
• Ubuntu 18.04: v3.10.2
• NVIDIA L4T 32.4.3: v3.10.2

Technically we're still supporting 16.04, but with the release of Ubuntu 20.04 I don't personally have a problem deprecating <18.04. Are there specifically features in CMake 3.10 that we'd benefit from relative to 3.5?

[MikeGitb]

From the top of my head: The cxx_std_17 target property which could be useful on Windows (IIRC, cinder requires c++17 on windows now, but c++14 on linux correct?).
Of course there are a ton of other features, tweaks and changes, but I'd have to actually start working on the cinder cmake files and run tests to see if any of them are relevant. Maybe someone else has a better overview of what got added between 3.5 and 3.10.

[alias-r-cummins]

For me, the main reason to upgrade is that the Android build system ships with two versions of CMake - one forked from 3.6 and (I believe) the standard verion of 3.10.2.
https://developer.android.com/studio/projects/install-ndk

As you can probably imagine, using the standardized 3.10.2 version tends to make things run a lot smoother, because it's integrated with gradle. Otherwise, one can end up with lots of build script customization using shell scripts, custom gradle plugins, etc. There were lots of unusual tooling decisions in earlier Android NDK versions, but a lot if it has been standardized now since the NDK 21 LTS release.

So for Android at least, unless legacy support is needed, I'd recommend using 3.10.2, just because it works out of the box with the SDK.

[andrewfb]

@MikeGitb yes we're standardized on C++17 on MSW and C++14 elsewhere.

And this seems like a fair trade-off to me. <=Ubuntu 16.04 looks like the only platform that would be affected if we standardize on 3.10.2 - let's do it.

[MikeGitb]

@andrewfb : sounds good - I can't promise I'll work on that in the near future (next couple of weeks are pretty full) but at least now we have a concrete target to work and test against.
@ufidstudios-ch : Are you already working on modifications of the cmake files. Just so we don't collide.

[alias-r-cummins]

I've just begun, but if you have any insights I'd be happy to incorporate them into my branch?

[MikeGitb]

From the top of my head, I'd remove the whole c++ standard selection machinery and maybe add cxx_std_14/17 (linux/windows) to the public compilation requirements (I'm having somewhat ambivalent feelings towards them, but that's a different story). There might be other cleanup possible, now that VS2019 is the only supported VS-version. Other than that I haven't really been looking into this for quite some time and I've never developed anything for android or MacOS/iOS so I don't know anything about that area.
I think, I'll best just ping you again, before I'm going to start any work on this.

IIRC, there are a few other cmake-related PRs in flight that you might want to take a look at, but they might be outdated by now.

[MikeGitb]

I should mention that I'm by no means a cmake expert.

[alias-r-cummins]

Great, please do! - I'll get started on cleaning things up on my side.