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.

Sign up for GitHub

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

Jump to bottom

What CMake version to require #41

Closed
certik opened this issue Dec 22, 2019 · 20 comments
Closed

What CMake version to require #41

certik opened this issue Dec 22, 2019 · 20 comments

Comments

@certik
Copy link
Member

certik commented Dec 22, 2019

What minimal CMake version should we require?
@certik certik mentioned this issue Dec 22, 2019
Closed
3 tasks
@milancurcic
Copy link
Member

I think we should look at the features we want to use in our CMake builds, and then get to the lowest version that satisfies all. I anticipate that of users who have and would use CMake to build stdlib, many don't have the latest version, and some (like me) get their CMake from the OS package manager. When the OS support for CMake runs our, you stay with that CMake version. My version is 3.14.3.

I don't see this as a general philosophy we should take, but rather an exception we should make for CMake -- it's changing a lot throughout versions, newest versions are not ubiquitous among systems that have CMake, and CMake itself is not ubiquitous among systems in general. For some advanced users, it may be easy to get the latest CMake on their system. For the majority it isn't, from my experience with other HPC users that I've support in the past, and for my readers it's the same. A novice Fortran programmer should have an easy time getting started with stdlib.

If it's decided not use a suitably new CMake I probably won't be motivated to contribute.

@zbeekman Can you write in more detail what would be suitably new CMake? What are the features that you need? We're not using MPI or submodules yet. Let's worry about updating our CMake system when we do.

Also can you elaborate on what do you mean by being motivated to contribute? Do you mean you wouldn't be motivated to maintain somewhat older-version CMake builds, or you wouldn't be motivated to contribute to stdlib at all?

@zbeekman
Copy link
Member

I think 3.14.3 should be the minimal version due to good submodule support and other bug fixes. As I noted on the PR where @certik and I were discussing this:

  1. It's trivial to download and install a statically linked, relocatable, pre-compiled binary. On linux the self-extracting script is easy to use and lets you put this in your home directory if you don't have root, or in the "normal" location.
  2. Kitware cryptographically signs these so you can be pretty darn confident you're not falling victim to an open source supply chain attack
  3. You can always install the latest CMake with pip, into your USERBASE prefix or the system wide site-packages
  4. If a makefile is also being maintained and/or we expect consumers to copy sources into their source tree and bring their own build system there is little/no harm in using a newer CMake.

While we're not currently using any submodules, separating the interface and implementation helps avoid circular dependencies and makes the builds faster once we have more SLOC.

newest versions are not ubiquitous among systems that have CMake

very sad, but true

and CMake itself is not ubiquitous among systems in general

I don't think this is really true anymore...

If it's decided not use a suitably new CMake I probably won't be motivated to contribute.

Sorry, I was getting a little grumpy. But at the end of the day it's so frustrating as a Fortran programmer to be handicapped by lack of good Fortran support in tools, compilers, and open libraries. CMake is one of the few tools out there with GREAT, first class Fortran support. Handicapping my ability to write and build good Fortran simply because user X only has a super antiquated CMake version installed by default on their system would likely lead me to become frustrated and stop contributing all together or fork the project and maintain my own version with a suitably sophisticated build system. Especially given how easy it is to get a binary distribution of CMake and install it in your home directory.

@milancurcic
Copy link
Member

Sorry, I was getting a little grumpy. But at the end of the day it's so frustrating as a Fortran programmer to be handicapped by lack of good Fortran support in tools, compilers, and open libraries. CMake is one of the few tools out there with GREAT, first class Fortran support.

No worries, it happens to all of us, and I agree that CMake offers great first class Fortran support. It's the right tool to build a project like this.

Handicapping my ability to write and build good Fortran simply because user X only has a super antiquated CMake version installed by default on their system would likely lead me to become frustrated and stop contributing all together or fork the project and maintain my own version with a suitably sophisticated build system.

I don't think anybody here in the community wants that. From knowing the community and people involved here so far, I think it's highly unlikely that we'd choose to hold back on some obvious beneficial features of CMake in order to keep one or few users happy. In the end, for users like that, there will be the manual Makefiles, and they'll be able to build one way or another. CMake is here to make a) our lives easier, and b) lives of stdlib users that have a recent-enough CMake. I believe it's part of our mission, and in stdlib's best interest, to make the scope of b) as wide as possible. We can do this by choosing to not enforce the latest CMake, but to use a reasonably recent version that delivers what we need.

In summary, to broaden the scope of stdlib users that will build stdlib using CMake (ultimately, I think most of us here prefer that to manual Makefiles), we need to chose the oldest version that we can, while not handicapping any developer's work with Fortran or CMake.

Handicapping my ability to write and build good Fortran

We need to all get clear and explicit about what are the features we need from CMake. This is exactly what this issue is for. Let's discuss. Zaak, can you spell out exactly what you need from it so that you don't feel handicapped for Fortran development? It's important that we get clear on these so that you can get what you need for your work, and which is supported by the community.

@certik
Copy link
Member Author

certik commented Dec 23, 2019

It's a friction between developers (who want to use the latest language, the latest compilers and the latest tools) and users, who want exactly the opposite: they want our library to work with the compilers they have and tools that they have. And we definitely want to ensure that our code is used by as many users as possible. At the same time, we want to get as many developers as possible. So we have to strike a balance. @zbeekman I think all we are asking is that you try to work with us and I think we can figure out a compromise so that you will get what you want, while our (future) users also get what they want.

@zbeekman
Copy link
Member

zbeekman commented Dec 30, 2019 via email

@zbeekman
Copy link
Member

So, just to summarize I advocate for using 3.14.3 because:

  1. Submodule support
  2. It's what I'm used to
  3. CMake is very easy to install as a binary, an alternate Makefile system is being provided and users are assumed to just plunk the sources into their own source tree in many cases and bring their own build system
  4. By the time lots of people start adopting this library 3.14.3 will be pretty old anyway
  5. I know there are a number of bugs and other issues that have bitten me in versions prior to 3.14.3 in my extensive experience supporting large Fortran & mixed language apps on the three major OSes including supporting Intel Fortran and MSVS builds on Windows
  6. I can't keep track of all the fixed bugs, new features, etc. and frankly don't want to put in the effort to test older versions and adapt to not using constructs & features added before 3.14.3
  7. A user with an old CMake that hits a bug (either in CMake itself or the build system implementation) will be more irritated than a users who is pointed in the direction of upgrading their CMake if they want to use CMake instead of the Makefiles or their own solution.

@milancurcic
Copy link
Member

Thanks Zaak, I'm getting a bit better idea on where you are on this.

My impression is that many of your concerns about this assume that you'd be the only person maintaining the build system, which I hope doesn't happen considering that we're building a community here. There's already several of us and more people will get involved in time.

I also understand that Zaak, you implicitly agree that we need some CMake versions for specific features, and not just because, is that right? Your point 1) (submodules) + bug fixes is an important one. Although we're not using submodules yet, we likely will soon. It's worth it to think ahead. In this case, one of us (no pressure on you) could do the research about the minimum CMake version that we need now, and bump it up to 3.14.3 later in 2020 when we start using submodules.

Btw, I can't find anything about submodules in the release notes for 3.14. Was the submodule support perhaps added before or after 3.14?

@marshallward @jacobwilliams @ivan-pi @jvdp1 @scivision Do you mind weighing in here with
your perspective? I'd like to get as many eyes on this as we can.

Question for everybody: do we really need cmake_minimum_required? What if we didn't enfoce it in the CMakeLists, but stated in the README what is the recommended version? In this scenario, we don't penalize users with CMake versions that can build stdlib but don't meet the cmake_minimum_required.

This approach only takes care of the scenario where we enforce some later CMake version that we don't yet need. If we can agree to do the proper research and determine the correct CMake version needed, then we can just require that one.

@zbeekman
Copy link
Member

Btw, I can't find anything about submodules in the release notes for 3.14. Was the submodule support perhaps added before or after 3.14?

Submodule support was added in 3.13 (IIRC) but it was broken/buggy.

Question for everybody: do we really need cmake_minimum_required? What if we didn't enforce it in the CMakeLists, but stated in the README what is the recommended version? In this scenario, we don't penalize users with CMake versions that can build stdlib but don't meet the cmake_minimum_required.

You need it because:

  1. It influences whether new or old behavior is used for CMake policies. These are a mechanism to change behavior and let projects opt-in to the new behavior over time. So this may have unintended consequences even if the build appears to work, it's conceivable that a difference in policy might cause unintended things to happen at runtime.
  2. All policies will be set to old
  3. CMake adds new syntax and features over time. Using these without setting the correct cmake_minimum_requred means that you're telling your users I promise that your CMake will work with my build system, but then it doesn't.

In my opinion it's non-optional because it leads to unexpected variability.

At the end of the day the goal is to make life easy on users and developers. People have a tendency to hate CMake to begin with. Providing a build system without cmake_minimum_required will inevitably lead to someone using ancient CMake 2.8 and failures galore. Providing an inaccurate cmake_minimum_required will lead to a build failure or misconfiguration that will be much more frustrating than being told up front to upgrade CMake.

My impression is that many of your concerns about this assume that you'd be the only person maintaining the build system, which I hope doesn't happen considering that we're building a community here. There's already several of us and more people will get involved in time.

Well, I hope to help out a lot, and my fear is more that I will contribute code to the build system that will cause a problem for users down the road. I don't want to write buggy code, and for users to swear off this project (or CMake) because of a mistake on my part. I'm looking forward to working with all of you on the build system and every other part of this project.

@scivision
Copy link
Member

I agree, there were substantial developer and user quality-of-life improvements in CMake 3.13 and 3.14. However to start, I think 3.12 may be enough--let's see if it gets too annoying. That is, consider supporting CMake back to 3.12 until it becomes a real-life issue.

Ensuring project works with minimum CMake version

The method I use to ensure CMake 3.12 is OK is CI using Ubuntu 18.04 that has CMake 3.12. Simultaneously I have other CI images with the latest CMake release.

ancient CMake

parts of stdlib that don't use Fortran submodule can be supported back to CMake 3.7, where CMake statements can be used to fence off submodule targets like

if(CMAKE_VERSION VERSION_LESS 3.12)

CMake older than 3.7 is substantially more difficult to support. I don't have any projects that support older than CMake 3.7. Almost all my Fortran projects require at least CMake 3.12 due to Fortran submodule.

@scivision
Copy link
Member

if

cmake_minimum_required(VERSION 3.12)

is omitted, CMake emits several lines of warnings and proceeds. I think this line should be included to avoid issues with CMake policies as Zaak noted above.

@scivision
Copy link
Member

So in my opinion, I would start off with minimum CMake 3.12 and then see if:

  • too many users complain about wanting older CMake
  • too many devs complain about accommodating older CMake

@zbeekman
Copy link
Member

For the record, significant issues persisted until 3.13.4. I can try to find the bug(s) if anyone really cares, but I do not trust CMake < 3.13.4 to work reliably on all 3 oses with Fortran Submodules.

@certik
Copy link
Member Author

certik commented Dec 30, 2019 •
edited
Loading

I follow a pragmatic approach, that I recommend we follow also:

  1. Use the oldest possible CMake that still works on all platforms.

  2. If substantial amount of ugly hacks and code have to be implemented in our CMake files, that would be eliminated if we simply upgraded CMake, then we should strongly consider upgrading CMake, when this case arises, and make the decision which CMake version to upgrade to based on the actual feature needed in a given PR.

Until now this discussion was not relevant, because our CMake build system was clean and worked with old CMake. In #54 the new Windows CI would either require ugly hacks, or an upgraded CMake. As I commented there (#54 (comment)), let's upgrade CMake to 3.14.

@zbeekman if I may recommend, why not to follow the approach I just outlined above?

Instead of imposing tools on others that might not be necessary, let's assume that we are all reasonable and let's instead spend our energy and discussions on the actual API of stdlib and other things that actually matter to our (future) users. If some of our tools choice forces us to create complicated workarounds, let's instead upgrade our tools.

We have much bigger fish to fry than a CMake version.

@scivision
Copy link
Member

To have more complete use of Fortran syntax, some of that syntax needs to be tested at build configure time as maintaining whitelists for OS and compiler versions would be an endless task. That would be another clear driver for CMake 3.14 along with the CMake bugs for modern Fortran before CMake 3.14

@zbeekman
Copy link
Member

Until now this discussion was not relevant, because our CMake build system was clean and worked with old CMake. In #54 the new Windows CI would either require ugly hacks, or an upgraded CMake. As I commented there (#54 (comment)), let's upgrade CMake to 3.14.

I think a lot of the text (NOT quoted here) in that comment is now outdated and conflicts with your edit, @certik. Based on discussion in #54 do we all now see a case for setting the minimum to 3.14? There are other bugs and issues in addition to the reasons mentioned above and in #54 too, but, again, I don't have the time or energy to recall and hunt them all down. (Although, given the amount of back and forth, that might have been less work: you guys are sticklers 😜.)

@zbeekman
Copy link
Member

(and if we're in agreement, close this issue... a new one can always be opened if someone wants to downgrade 😱 or upgrade 👿 CMake.)

@certik
Copy link
Member Author

certik commented Dec 31, 2019

I think a lot of the text (NOT quoted here) in that comment is now outdated and conflicts with your edit, @certik.

I don't follow.

My question is, do you agree with my proposition in #41 (comment), or not? And if not, why not?

@milancurcic
Copy link
Member

and if we're in agreement, close this issue

IMO, no need to rush. Let's keep it open and have the discussion going. Plus, I don't want to hide this thread from the top of the issues page.

It's not the specific version number that matters, but the process through which we arrive there. I'm not convinced we've nailed down the process.

I agree that the Windows tests are indeed important and agree that we can go with 3.14. As a bonus, we get the bug-free submodule, which will be important when we start adding submodules.

@zbeekman
Copy link
Member

I agree. You may safely disregard my comment about @certik's edited post... My point was that when your comment was edited, at one point it seemed inconsistent to me. At the end of the day I agree with you. Thankfully @scivision has pointed out some compelling cases to upgrade the version, where my memory for specifics has failed me.

Please accept my apology if you think I've seemed contrary, difficult, arbitrary or cantankerous, that was never my intention.

At any rate, I believe we are all in agreement. I agree with everything you (@certik) and @milancurcic have said, and I'm happy that someone else pointed out a few of the concrete reasons why 3.14 should be used. I did not want to bump the minimum version solely to have newer features despite the fact that I couldn't easily point to defects it resolves or needed capabilities it added.

As far as the process goes, I completely agree that it should NOT be upgraded unless there is a compelling concrete need. I don't foresee us wanting to version bump beyond 3.14 anytime soon, and should that occasion occur, it will be based on a recent bug discovery or missing feature so it will be easy to articulate & remember at the time it comes up. (In contrast to the ~2 years of running down compiler and CMake bugs for the project I contribute to for work.)

So I 100% agree with the general principle of not upgrading unless there is a need. I also fully anticipate being able to express that need with concrete examples should it arise in the future as we work on stdlib.

We can keep this issue open if you think it requires further discussion or want other people to weigh in.

@milancurcic
Copy link
Member

This has been in active for over a year and what we chose to do has been working so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@certik @zbeekman @milancurcic @scivision