Raising CMake minimum version to 3.4.3

As one of the OS' without current CMake support, I'm closely watching this discussion. We currently have LLVM 3.4.2 hosted on OpenVMS Itanium (as a host only, x86 target) using configure/make with little hassle. We plan to port CMake to OpenVMS, but that has been trickier than you'd think (others have tried, I haven't found anybody who has done it). Looks like I'll want to visit the cmake-developers list to as we get farther along.

The "lets update every year just because" does have ripple effects for us non-traditional platforms.


Thank you John, with some concrete arguments to my earlier attempt to
hold the horses.

As far as ARM is concerned, it's probably fine to upgrade (we've done
most of the work last week), but there are platforms that make ARM
testing look easy. :slight_smile:

I'm adding some MIPS, PPC and release folks to make sure there's
nothing else we're missing.


I'm not aware of any problems with this for MIPS. The buildbots I admin already use backported versions of cmake and ninja and it's not much more of a burden to have additional versions installed to non-standard prefixes. I'll find out whether that's ok for the MIPS buildbot that I don't admin.

It sounds like your problem is with having cmake working at all, not which version is required…So I’m not sure how requiring an upgrade every year could make that any worse.

If anything, I’d expect you to need a newer version in order to get porting changes.

It depends on the extent of our changes and the extent of the yearly differences in CMake. Some might merge easily, some might require re-engineering if the underlying code has major changes. Having a “fetch me a shrubbery” exercise once a year and hope we aren’t surprised is just something I’d rather not have to do. We already have to worry about any out-of-tree merges into newer LLVMs. At some point as we get farther along, I’ll come back here and see what sort of stuff we can check into the tree. For example, getting our own triple into the tree would be a good start. However, I suspect we’re over a year away from any of those discussions.

Of course the real solution would be to work with the CMake folks and provide/support some OpenVMS support or at least follow THEIR development discussions. Just more work for my small team.

I'm not sure if they are doing an x86 to IA64 cross compile, but in
any event I'm going to guess they may need an ancient version to avoid
any C++11 dependencies. In terms of IA64 compilers you have afaik 3
choices HP compiler, Open64 and Intel? (Does gcc still support it and
how up-to-date or EOL is the Intel compiler IA64 support?)

I really hope nobody decides not to move to a more recent version of
cmake because of IA-64.

I'm happy to share what our strategy for porting OpenVMS to x86 using LLVM, but I don't want to distract from the original question. I was just stating that bumping the minimum CMake version yearly just because you can easily get newer kits from cmake.org isn't true for me. I have no problem saying that 3.4.3 is the minimum version. Or even 3.5.2. I don't care.

I will only be using CMake when we have working OpenVMS x86 systems. The fact that I'm starting on IA-64 hosts is not relevant.

A few things.

First I don’t think anyone is suggesting we should update *ever* “just because”. In fact, I think as a community we’ve held a pretty high bar for updating the CMake dependency favoring keeping it stable. Notice my failed attempt to move to CMake 3.1 last year.

Second, I’d really like to keep discussions of future updates to the version separate from the current update. I know I started this all in my email by stating “...we may find ourselves re-visiting this conversation in a year or two…”, but let’s please not entangle to two.

I want to stress that what I was suggesting originally was that we may find compelling reasons to update our CMake version in the future. The CMake developers are actively adding new and useful features and we *might* find that new features are valuable enough to raise our minimum version again in another year or two. Alternatively we might find that we’re happy on 3.4.3 for the next decade.

Despite my problems keeping track of dates, my love of DeLoreans, and my affinity toward driving at 88 MPH, I am not a time traveler. I have no idea what the future holds. I just don’t think we should hold back our project by being unwilling to revisit this conversation. It is still a conversation. Nobody is suggesting we should commit to a regular update schedule for kicks.