Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider upgrading CMake to latest release #8201

Closed
fsimonis opened this issue Jun 7, 2020 · 8 comments
Closed

Consider upgrading CMake to latest release #8201

fsimonis opened this issue Jun 7, 2020 · 8 comments

Comments

@fsimonis
Copy link
Contributor

@fsimonis fsimonis commented Jun 7, 2020

Rational

OpenTTD is an application with no dependants. Thus only CI, packagers and developers ever need to configure the build system.

Installing the latest CMake is as easy as downloading and extracting an archive.
Windows is also not an issue as CMake needs to be installed by hand anyhow, so there is no reason to install an old version.

Upsides

  • Latest find modules for dependencies
  • Improved working with targets allowing for a cleaner build system
  • Latest versions of package generators there were some unpleasant bugs in the debian generator
  • Improved handling of file installation by type

Downside

One more trivial step to get started to develop OpenTTD.

@LordAro
Copy link
Member

@LordAro LordAro commented Jun 7, 2020

As far as I'm concerned, we should (at least!) be compatible with the packages that come with Debian stable. As of right now (Debian Buster), that is CMake 3.13. To support oldstable (which would be recommended, imo), that would be 3.7.

There's also likely going to be issues in future with whatever version of cmake VS 2019 is bundled with, as it likely won't be updated often either.

TL;DR Updating and/or installing a dependency is not necessarily trivial

@fsimonis
Copy link
Contributor Author

@fsimonis fsimonis commented Jun 8, 2020

CMake is a build-only dependency and does not end up in generated packages.
Thus this is not a problem, as long as Debian does not require a package to be buildable from source with system packages only.

There's also likely going to be issues in future with whatever version of cmake VS 2019 is bundled with, as it likely won't be updated often either.

I did not find any official information on which version of CMake is bundled with visual studio. I found this post which mentions Visual Studio 16.3.2 shipping CMake 3.15.3.
Do you have more information on that matter?

As of right now (Debian Buster), that is CMake 3.13.

The CPack Debian Generator was updated in releases 3.6, 3.7, 3.10, 3.13, 3.16.
So upgrading to 3.13 would already be a major leap forward especially in terms of package generation.
Installation file types were added in 3.14.

@LordAro
Copy link
Member

@LordAro LordAro commented Jun 8, 2020

Thus this is not a problem, as long as Debian does not require a package to be buildable from source with system packages only.

Guess what.

Of course, Debian itself doesn't upgrade major versions of packages on the same distro, but the fact remains, I don't want to ask users to have to add a PPA/package repo just to build OTTD.

@fsimonis
Copy link
Contributor Author

@fsimonis fsimonis commented Jun 8, 2020

I did some more digging regarding the current Debian packages, so please correct me if I am wrong.

  • The Debian OpenTTD packages are automatically generated using the source package located here.
  • The generated packages are then synchronized into the ubuntu universe repository.
  • This means that currently OpenTTD does not need to generate DEB packages via CPack to be available in Debian and Ubuntu.

CPack is only necessary to generate the separate set of Debian packages provided in the OpenTTD download section. The latter is then what the item in the original CMake PR referred to.

This then boils down to the usual baseline question.
Are you (as in maintainers) prepared to drop support for debian strech (oldstable) and Ubuntu 16.04 to improve the generation of packages in your own pipeline?


I don't want to ask users to have to add a PPA/package repo just to build OTTD.

I understand the argument, but this only affects developers. Using a separate version of CMake really only involves extracting an archive. Everything works out of the box and even extending PATH isn't required.

@glx22
Copy link
Contributor

@glx22 glx22 commented Jun 8, 2020

Maybe @matthijskooijman has an opinion about this.

@HotelCalifornia
Copy link

@HotelCalifornia HotelCalifornia commented Jul 8, 2020

question: what exactly is this issue suggesting? bump the minimum required CMake version?

users can use whatever version they want as long as it's higher than 3.5, no action required on the part of the maintainers...

@fsimonis
Copy link
Contributor Author

@fsimonis fsimonis commented Jul 8, 2020

question: what exactly is this issue suggesting? bump the minimum required CMake version?

Yes, the issue suggests to bump the minimum required CMake version as high as possible/feasible.
This is about allowing the developers to further modernize the build system.

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Dec 12, 2020

Development dependencies should always be kept at the lowest version as possible, without hurting development itself (which makes this very subjective). You want developers to be able to jump in and start coding, without having to upgrade all the latest versions of all the dependencies all the time. This would drive away contributors, instead of pulling them in. There is a balance at play here, and that is always a bit difficult to navigate.

The current minimum required CMake version was picked when we switched to CMake, and so far we haven't seen any new features that makes it worth switching to a newer version for us. Sure there are the odds bits and pieces, but nothing worth making everyone go through the motions. So in that respect we fully comply with your request: our minimum required CMake version is as high as possible/feasible to us ;)

The most likely case the minimum required version would be bumped, is when we introduce a new (game) feature that is a lot easier to build with a newer version. To give a hypothetical example: say, we want to use libcurl, and CMake 3.20 (to be released) makes that 2 lines of code instead of 300 lines of custom code. That is a moment increasing the minimum required version is worth considering. Till that time, we are not going to bump anything for the sake of bumping.

If you have anything specific in mind, feel free to create a Pull Request (can be a draft, if you want to feel the waters) which shows us how that looks.

For CMake specific, we will have targets that require a lot newer CMake in order to build OpenTTD correctly, for example the newest Mac OS ARM. It will not build correctly on CMake 3.18 and below (if I am not mistaken). But these limitations are OS specific, and are due to bugs of CMake. It does not give sufficient reason for us to bump the minimum required version for all OSes. As @LordAro pointed out, OpenTTD still builds fine on Ubuntu 16.04 without dragging in any PPA. I see no reason, and no argument is given in this thread, to change this.

We can be convinced otherwise, but it needs more than "bumping for the sake of bumping!" :) Hope you understand ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants