There are plenty of orgs that don’t allow internet connections and strictly control what data can come into and out of a system. There are also plenty of orgs that say “you must use these tools, and that’s final”. Surely these cases are a minority of users, but the fact is that there are those for whom using a newer cmake is not trivial. Upgrading the minimum cmake version is reducing the accessibility of building LLVM, and this is, strictly speaking, not a good thing.
Should we hold ourselves hostage to these users? In my opinion, we should not. If upgrading to CMake version X allows us to use a CMake feature that will add value to the project, we should consider it. However, if we just say “Well, most distros that we think most people use have CMake version X, we might as well just upgrade to that because maybe somebody wants to use a feature in version X”, then we are disenfranchising users for some unknown gain.
I agree that a build system is software. It has an architecture. I’ve never worked on a C++ project that just upgrades the C++ standard version periodically just because. Someone does cost-benefit analysis and determines that the time is right for an upgrade. LLVM itself is still on 14, when 17 is already available. Why should the CMake version be any different?
I guess my position is: it is probably fine to upgrade the CMake version. Upgrading to 3.8 sounds justified to me. I think a good case could probably be made for 3.12. But we should not just periodically bump the version minimum bound. Somebody should always make a conscious choice to upgrade the CMake version.
Those are all good points, and I agree with you that using a newer CMake version just because it’s available isn’t the right approach, and we should discuss the actual benefits we gain from upgrading. There’s going to be differences of opinions about what features are worth upgrading for, but we can at least try to establish policies around e.g. which LTS versions we should consider when looking at the CMake versions that are available on various distros (as is being discussed in the other thread).
One other question I had about this sort of setup. Does the availability of certain software versions in the official software repositories make a difference? E.g. if you’re running CentOS 7, and you have CMake 3.14.7 available in the EPEL, would you be able to get that version? What about things like third-party apt repositories, like the CMake apt repository for Ubuntu?
It varies from org to org, but since most orgs that I’m familiar with that do this sort of stuff do it to control the environment, third party repos and building from source would likely be frowned upon.
There’s no way you can really know, which is why I don’t think we should worry about their specific configurations. But when we consider a version upgrade, we should consider the fact that it may mean that an org that could previously build llvm will no longer be able to. Raising barriers to entry limits the reach of the project, so it’s not an unmitigated win, which is why I think we should only upgrade for a specific reason.
There are plenty of orgs that don’t allow internet connections and strictly control what data can come into and out of a system. There are also plenty of orgs that say “you must use these tools, and that’s final”.
Are there really “plenty of orgs” that would be OK to provide you a complete C++ build environment and let you build one software downloaded from GitHub (LLVM) but not another (CMake)?
CMake is not that big, if we included the CMake sources in the monorepo would that change anything for such orgs?
An org that audits all external code may not be happy to have to start auditing CMake as well.
Regardless of that, I would personally be opposed to requiring people build the bundled CMake before building LLVM. My fear is that if the CMake sources are included in the repo, it’s only a matter of time before that mirror becomes a fork with custom patches, and the process for building LLVM becomes: