Shoaib Meenai via llvm-dev
2020-Mar-26 21:47 UTC
[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi
I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to clarify that you don’t need to sudo.) From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Chris Tetreault <ctetreau at quicinc.com> Date: Thursday, March 26, 2020 at 2:06 PM To: "ldionne at apple.com" <ldionne at apple.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi Wanting to use new features is a good reason to upgrade. You say you need 3.8 in order to compile C++17 code, which is needed by your subproject. This is a good reason to upgrade the version. The proposed policy of bumping the CMake minimum version periodically to within some distance of bleeding edge “just because” is what I object to. We should decide what cmake features we want to use, justify them to ourselves, and then upgrade the version to the lowest version that supports the required new features. We shouldn’t institute a policy of “we upgrade the CMake version to (latest release – N) every T time interval”. As for the difficulty of upgrading CMake on a target machine; no amount of “it’s really easy to do a thing” can make up for “my organization will not allow me to do a thing.” From: ldionne at apple.com <ldionne at apple.com> Sent: Thursday, March 26, 2020 7:33 AM To: Chris Tetreault <ctetreau at quicinc.com> Cc: Nikita Popov <nikita.ppv at gmail.com>; Libc++ Dev <libcxx-dev at lists.llvm.org>; llvm-dev at lists.llvm.org Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> wrote: I would like to just chime in and say that I’m fairly strongly opposed to any blanket version increases without justification. Having a low version requirement is a feature. It means that more people can build the codebase. We should increase the minimum CMake version requirement only if we need to do so in order to use a new feature. We should be disciplined in deciding when to use new features if they result in the minimum CMake version being increased too much. What recent Linux LTS distros ship can help inform these decisions, but we shouldn’t just upgrade the minimum CMake version to version X just because Linux distro Y ships that version. The reason for wanting to upgrade is evidently the use of new features that would simplify and clean up the build system quite a bit. I can't speak for other projects, but libc++ and libc++abi are suffering a lot from the lack of e.g. compile_features in recent CMakes. Anybody who has ever needed to build something on some ancient version of CentOS because work refuses to upgrade will thank you. Honestly, CMake is so easy to install that I have a hard time relating: curl -L https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.sh | bash /dev/stdin --skip-license --prefix=<YOUR-INSTALLATION-PREFIX> This takes about 10 seconds to run and you've got yourself the latest CMake. I understand how upgrading some tools is difficult, but CMake just isn't. Louis From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Louis Dionne via llvm-dev Sent: Wednesday, March 25, 2020 10:14 AM To: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> wrote: On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 03/25/2020 06:20 AM, Louis Dionne wrote:> > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com<mailto:tstellar at redhat.com>> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DOctober_136295.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=2921T7FXA_APW3xYrnSDPuKHRoTGqKh2hoUcUIUalVo&e=>. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM. > > My personal opinion is that there's a tendency to view all subprojects under the LLVM umbrella as a single, monolithic project. That leads to the desire to make decisions for the whole project, which is often difficult, as opposed to making the right decision for each subproject, which is often easier. This results on subprojects being blocked from doing the right thing for them, like we've seen happen for pre-commit CI. But that's a much larger (non-technical) discussion than the scope of a simple CMake version bump. > > Let's try to bump CMake for all of LLVM and see how that goes. > >> Yes, I agree we should bump the version for all of LLVM, but I don't >> think we should bump the version without a long-term cmake usage plan. >> e.g. something like: After every release branch, we bump the cmake version >> to whatever version of cmake is X months old. >> >> I think the concern that this was our one chance to bump the CMake version >> led to the choice of 3.15 as the next version, which would be too new for some Linux distros. >> I think if we had a planned upgrade path, it would be easier for those of us that >> want something really new to settle on a release that is a little bit older. > > Ok, how about the following policy: > > After every release branch, we bump the CMake version to whatever version of CMake is 12 months old. > > This is simple, straightforward, and it gives a full year of old CMakes being supported. If we did this right now, this would take us to CMake 3.14.0, released around March 14th, 2019 (https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe the expectation should be that recent CMakes are upgraded using some package manager or download from the site -- we can't really expect the CMake version to be the one provided by the system, because that is either non-existent or very old on most Linux distributions AFAICT. Fortunately, installing a new CMake is incredibly easy. > > Is everybody OK with the above policy? What would be the preferred place to document it? >12 months is fine with me. I'm not sure the best place to document the policy. Some suggestions are here: https://llvm.org/docs/CMake.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_CMake.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=j2EDcwI04BSohMxhGry1LMc2Jzxs84rBWyQ7X05lQH8&e=> or in the Programmer's manual. I think the relevant metric here needs to be "which version is available on current LTS distros", and not "how old is the release". The current cmake version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would be happy with a bump to that version, but not something newer. People using other distributions probably have other considerations. If someone wants to perform a cmake version bump, I believe the first step would be to gather what the cmake version availability across distros looks like right now, so an informed decision can be made. I'll actually suggest that we might want to do something else entirely. If we depend on the version available in distros, then we are at the mercy of those distros not updating. It also means that we need to look at several distributions and try to satisfy everybody. That's a lot harder than requiring that people download a recent CMake from cmake.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=VFvTnF8okYQ3GbWeCEjzVIsSw-rvgxPgALVBGP8udME&e=>. CMake has the benefit of being incredibly easy to install, either from source or with the binaries provided on their website. Do you think it's an unreasonable requirement to ask folks to download CMake instead of using the one provided with their OS? Louis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/c3c155eb/attachment-0001.html>
Chris Tetreault via llvm-dev
2020-Mar-26 22:14 UTC
[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi
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. From: Shoaib Meenai <smeenai at fb.com> Sent: Thursday, March 26, 2020 2:47 PM To: Chris Tetreault <ctetreau at quicinc.com>; ldionne at apple.com Cc: llvm-dev at lists.llvm.org; Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to clarify that you don’t need to sudo.) From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Reply-To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Date: Thursday, March 26, 2020 at 2:06 PM To: "ldionne at apple.com<mailto:ldionne at apple.com>" <ldionne at apple.com<mailto:ldionne at apple.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi Wanting to use new features is a good reason to upgrade. You say you need 3.8 in order to compile C++17 code, which is needed by your subproject. This is a good reason to upgrade the version. The proposed policy of bumping the CMake minimum version periodically to within some distance of bleeding edge “just because” is what I object to. We should decide what cmake features we want to use, justify them to ourselves, and then upgrade the version to the lowest version that supports the required new features. We shouldn’t institute a policy of “we upgrade the CMake version to (latest release – N) every T time interval”. As for the difficulty of upgrading CMake on a target machine; no amount of “it’s really easy to do a thing” can make up for “my organization will not allow me to do a thing.” From: ldionne at apple.com<mailto:ldionne at apple.com> <ldionne at apple.com<mailto:ldionne at apple.com>> Sent: Thursday, March 26, 2020 7:33 AM To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Cc: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> wrote: I would like to just chime in and say that I’m fairly strongly opposed to any blanket version increases without justification. Having a low version requirement is a feature. It means that more people can build the codebase. We should increase the minimum CMake version requirement only if we need to do so in order to use a new feature. We should be disciplined in deciding when to use new features if they result in the minimum CMake version being increased too much. What recent Linux LTS distros ship can help inform these decisions, but we shouldn’t just upgrade the minimum CMake version to version X just because Linux distro Y ships that version. The reason for wanting to upgrade is evidently the use of new features that would simplify and clean up the build system quite a bit. I can't speak for other projects, but libc++ and libc++abi are suffering a lot from the lack of e.g. compile_features in recent CMakes. Anybody who has ever needed to build something on some ancient version of CentOS because work refuses to upgrade will thank you. Honestly, CMake is so easy to install that I have a hard time relating: curl -L https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.sh | bash /dev/stdin --skip-license --prefix=<YOUR-INSTALLATION-PREFIX> This takes about 10 seconds to run and you've got yourself the latest CMake. I understand how upgrading some tools is difficult, but CMake just isn't. Louis From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Louis Dionne via llvm-dev Sent: Wednesday, March 25, 2020 10:14 AM To: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> wrote: On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 03/25/2020 06:20 AM, Louis Dionne wrote:> > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com<mailto:tstellar at redhat.com>> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DOctober_136295.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=2921T7FXA_APW3xYrnSDPuKHRoTGqKh2hoUcUIUalVo&e=>. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM. > > My personal opinion is that there's a tendency to view all subprojects under the LLVM umbrella as a single, monolithic project. That leads to the desire to make decisions for the whole project, which is often difficult, as opposed to making the right decision for each subproject, which is often easier. This results on subprojects being blocked from doing the right thing for them, like we've seen happen for pre-commit CI. But that's a much larger (non-technical) discussion than the scope of a simple CMake version bump. > > Let's try to bump CMake for all of LLVM and see how that goes. > >> Yes, I agree we should bump the version for all of LLVM, but I don't >> think we should bump the version without a long-term cmake usage plan. >> e.g. something like: After every release branch, we bump the cmake version >> to whatever version of cmake is X months old. >> >> I think the concern that this was our one chance to bump the CMake version >> led to the choice of 3.15 as the next version, which would be too new for some Linux distros. >> I think if we had a planned upgrade path, it would be easier for those of us that >> want something really new to settle on a release that is a little bit older. > > Ok, how about the following policy: > > After every release branch, we bump the CMake version to whatever version of CMake is 12 months old. > > This is simple, straightforward, and it gives a full year of old CMakes being supported. If we did this right now, this would take us to CMake 3.14.0, released around March 14th, 2019 (https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe the expectation should be that recent CMakes are upgraded using some package manager or download from the site -- we can't really expect the CMake version to be the one provided by the system, because that is either non-existent or very old on most Linux distributions AFAICT. Fortunately, installing a new CMake is incredibly easy. > > Is everybody OK with the above policy? What would be the preferred place to document it? >12 months is fine with me. I'm not sure the best place to document the policy. Some suggestions are here: https://llvm.org/docs/CMake.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_CMake.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=j2EDcwI04BSohMxhGry1LMc2Jzxs84rBWyQ7X05lQH8&e=> or in the Programmer's manual. I think the relevant metric here needs to be "which version is available on current LTS distros", and not "how old is the release". The current cmake version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would be happy with a bump to that version, but not something newer. People using other distributions probably have other considerations. If someone wants to perform a cmake version bump, I believe the first step would be to gather what the cmake version availability across distros looks like right now, so an informed decision can be made. I'll actually suggest that we might want to do something else entirely. If we depend on the version available in distros, then we are at the mercy of those distros not updating. It also means that we need to look at several distributions and try to satisfy everybody. That's a lot harder than requiring that people download a recent CMake from cmake.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=VFvTnF8okYQ3GbWeCEjzVIsSw-rvgxPgALVBGP8udME&e=>. CMake has the benefit of being incredibly easy to install, either from source or with the binaries provided on their website. Do you think it's an unreasonable requirement to ask folks to download CMake instead of using the one provided with their OS? Louis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/b59bbee9/attachment.html>
Shoaib Meenai via llvm-dev
2020-Mar-26 22:24 UTC
[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi
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). From: Chris Tetreault <ctetreau at quicinc.com> Date: Thursday, March 26, 2020 at 3:14 PM To: Shoaib Meenai <smeenai at fb.com>, "ldionne at apple.com" <ldionne at apple.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: RE: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi 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. From: Shoaib Meenai <smeenai at fb.com> Sent: Thursday, March 26, 2020 2:47 PM To: Chris Tetreault <ctetreau at quicinc.com>; ldionne at apple.com Cc: llvm-dev at lists.llvm.org; Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to clarify that you don’t need to sudo.) From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Reply-To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Date: Thursday, March 26, 2020 at 2:06 PM To: "ldionne at apple.com<mailto:ldionne at apple.com>" <ldionne at apple.com<mailto:ldionne at apple.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi Wanting to use new features is a good reason to upgrade. You say you need 3.8 in order to compile C++17 code, which is needed by your subproject. This is a good reason to upgrade the version. The proposed policy of bumping the CMake minimum version periodically to within some distance of bleeding edge “just because” is what I object to. We should decide what cmake features we want to use, justify them to ourselves, and then upgrade the version to the lowest version that supports the required new features. We shouldn’t institute a policy of “we upgrade the CMake version to (latest release – N) every T time interval”. As for the difficulty of upgrading CMake on a target machine; no amount of “it’s really easy to do a thing” can make up for “my organization will not allow me to do a thing.” From: ldionne at apple.com<mailto:ldionne at apple.com> <ldionne at apple.com<mailto:ldionne at apple.com>> Sent: Thursday, March 26, 2020 7:33 AM To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Cc: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> wrote: I would like to just chime in and say that I’m fairly strongly opposed to any blanket version increases without justification. Having a low version requirement is a feature. It means that more people can build the codebase. We should increase the minimum CMake version requirement only if we need to do so in order to use a new feature. We should be disciplined in deciding when to use new features if they result in the minimum CMake version being increased too much. What recent Linux LTS distros ship can help inform these decisions, but we shouldn’t just upgrade the minimum CMake version to version X just because Linux distro Y ships that version. The reason for wanting to upgrade is evidently the use of new features that would simplify and clean up the build system quite a bit. I can't speak for other projects, but libc++ and libc++abi are suffering a lot from the lack of e.g. compile_features in recent CMakes. Anybody who has ever needed to build something on some ancient version of CentOS because work refuses to upgrade will thank you. Honestly, CMake is so easy to install that I have a hard time relating: curl -L https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.sh | bash /dev/stdin --skip-license --prefix=<YOUR-INSTALLATION-PREFIX> This takes about 10 seconds to run and you've got yourself the latest CMake. I understand how upgrading some tools is difficult, but CMake just isn't. Louis From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Louis Dionne via llvm-dev Sent: Wednesday, March 25, 2020 10:14 AM To: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> wrote: On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 03/25/2020 06:20 AM, Louis Dionne wrote:> > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com<mailto:tstellar at redhat.com>> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DOctober_136295.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=2921T7FXA_APW3xYrnSDPuKHRoTGqKh2hoUcUIUalVo&e=>. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM. > > My personal opinion is that there's a tendency to view all subprojects under the LLVM umbrella as a single, monolithic project. That leads to the desire to make decisions for the whole project, which is often difficult, as opposed to making the right decision for each subproject, which is often easier. This results on subprojects being blocked from doing the right thing for them, like we've seen happen for pre-commit CI. But that's a much larger (non-technical) discussion than the scope of a simple CMake version bump. > > Let's try to bump CMake for all of LLVM and see how that goes. > >> Yes, I agree we should bump the version for all of LLVM, but I don't >> think we should bump the version without a long-term cmake usage plan. >> e.g. something like: After every release branch, we bump the cmake version >> to whatever version of cmake is X months old. >> >> I think the concern that this was our one chance to bump the CMake version >> led to the choice of 3.15 as the next version, which would be too new for some Linux distros. >> I think if we had a planned upgrade path, it would be easier for those of us that >> want something really new to settle on a release that is a little bit older. > > Ok, how about the following policy: > > After every release branch, we bump the CMake version to whatever version of CMake is 12 months old. > > This is simple, straightforward, and it gives a full year of old CMakes being supported. If we did this right now, this would take us to CMake 3.14.0, released around March 14th, 2019 (https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe the expectation should be that recent CMakes are upgraded using some package manager or download from the site -- we can't really expect the CMake version to be the one provided by the system, because that is either non-existent or very old on most Linux distributions AFAICT. Fortunately, installing a new CMake is incredibly easy. > > Is everybody OK with the above policy? What would be the preferred place to document it? >12 months is fine with me. I'm not sure the best place to document the policy. Some suggestions are here: https://llvm.org/docs/CMake.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_CMake.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=j2EDcwI04BSohMxhGry1LMc2Jzxs84rBWyQ7X05lQH8&e=> or in the Programmer's manual. I think the relevant metric here needs to be "which version is available on current LTS distros", and not "how old is the release". The current cmake version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would be happy with a bump to that version, but not something newer. People using other distributions probably have other considerations. If someone wants to perform a cmake version bump, I believe the first step would be to gather what the cmake version availability across distros looks like right now, so an informed decision can be made. I'll actually suggest that we might want to do something else entirely. If we depend on the version available in distros, then we are at the mercy of those distros not updating. It also means that we need to look at several distributions and try to satisfy everybody. That's a lot harder than requiring that people download a recent CMake from cmake.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=VFvTnF8okYQ3GbWeCEjzVIsSw-rvgxPgALVBGP8udME&e=>. CMake has the benefit of being incredibly easy to install, either from source or with the binaries provided on their website. Do you think it's an unreasonable requirement to ask folks to download CMake instead of using the one provided with their OS? Louis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/850cae44/attachment-0001.html>
Shoaib Meenai via llvm-dev
2020-Mar-27 18:35 UTC
[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi
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? From: Chris Tetreault <ctetreau at quicinc.com> Date: Thursday, March 26, 2020 at 3:14 PM To: Shoaib Meenai <smeenai at fb.com>, "ldionne at apple.com" <ldionne at apple.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: RE: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi 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. From: Shoaib Meenai <smeenai at fb.com> Sent: Thursday, March 26, 2020 2:47 PM To: Chris Tetreault <ctetreau at quicinc.com>; ldionne at apple.com Cc: llvm-dev at lists.llvm.org; Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to clarify that you don’t need to sudo.) From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Reply-To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Date: Thursday, March 26, 2020 at 2:06 PM To: "ldionne at apple.com<mailto:ldionne at apple.com>" <ldionne at apple.com<mailto:ldionne at apple.com>> Cc: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>, Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi Wanting to use new features is a good reason to upgrade. You say you need 3.8 in order to compile C++17 code, which is needed by your subproject. This is a good reason to upgrade the version. The proposed policy of bumping the CMake minimum version periodically to within some distance of bleeding edge “just because” is what I object to. We should decide what cmake features we want to use, justify them to ourselves, and then upgrade the version to the lowest version that supports the required new features. We shouldn’t institute a policy of “we upgrade the CMake version to (latest release – N) every T time interval”. As for the difficulty of upgrading CMake on a target machine; no amount of “it’s really easy to do a thing” can make up for “my organization will not allow me to do a thing.” From: ldionne at apple.com<mailto:ldionne at apple.com> <ldionne at apple.com<mailto:ldionne at apple.com>> Sent: Thursday, March 26, 2020 7:33 AM To: Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> Cc: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com<mailto:ctetreau at quicinc.com>> wrote: I would like to just chime in and say that I’m fairly strongly opposed to any blanket version increases without justification. Having a low version requirement is a feature. It means that more people can build the codebase. We should increase the minimum CMake version requirement only if we need to do so in order to use a new feature. We should be disciplined in deciding when to use new features if they result in the minimum CMake version being increased too much. What recent Linux LTS distros ship can help inform these decisions, but we shouldn’t just upgrade the minimum CMake version to version X just because Linux distro Y ships that version. The reason for wanting to upgrade is evidently the use of new features that would simplify and clean up the build system quite a bit. I can't speak for other projects, but libc++ and libc++abi are suffering a lot from the lack of e.g. compile_features in recent CMakes. Anybody who has ever needed to build something on some ancient version of CentOS because work refuses to upgrade will thank you. Honestly, CMake is so easy to install that I have a hard time relating: curl -L https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.sh | bash /dev/stdin --skip-license --prefix=<YOUR-INSTALLATION-PREFIX> This takes about 10 seconds to run and you've got yourself the latest CMake. I understand how upgrading some tools is difficult, but CMake just isn't. Louis From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Louis Dionne via llvm-dev Sent: Wednesday, March 25, 2020 10:14 AM To: Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>; Libc++ Dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com<mailto:nikita.ppv at gmail.com>> wrote: On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 03/25/2020 06:20 AM, Louis Dionne wrote:> > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com<mailto:tstellar at redhat.com>> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DOctober_136295.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=2921T7FXA_APW3xYrnSDPuKHRoTGqKh2hoUcUIUalVo&e=>. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM. > > My personal opinion is that there's a tendency to view all subprojects under the LLVM umbrella as a single, monolithic project. That leads to the desire to make decisions for the whole project, which is often difficult, as opposed to making the right decision for each subproject, which is often easier. This results on subprojects being blocked from doing the right thing for them, like we've seen happen for pre-commit CI. But that's a much larger (non-technical) discussion than the scope of a simple CMake version bump. > > Let's try to bump CMake for all of LLVM and see how that goes. > >> Yes, I agree we should bump the version for all of LLVM, but I don't >> think we should bump the version without a long-term cmake usage plan. >> e.g. something like: After every release branch, we bump the cmake version >> to whatever version of cmake is X months old. >> >> I think the concern that this was our one chance to bump the CMake version >> led to the choice of 3.15 as the next version, which would be too new for some Linux distros. >> I think if we had a planned upgrade path, it would be easier for those of us that >> want something really new to settle on a release that is a little bit older. > > Ok, how about the following policy: > > After every release branch, we bump the CMake version to whatever version of CMake is 12 months old. > > This is simple, straightforward, and it gives a full year of old CMakes being supported. If we did this right now, this would take us to CMake 3.14.0, released around March 14th, 2019 (https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe the expectation should be that recent CMakes are upgraded using some package manager or download from the site -- we can't really expect the CMake version to be the one provided by the system, because that is either non-existent or very old on most Linux distributions AFAICT. Fortunately, installing a new CMake is incredibly easy. > > Is everybody OK with the above policy? What would be the preferred place to document it? >12 months is fine with me. I'm not sure the best place to document the policy. Some suggestions are here: https://llvm.org/docs/CMake.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_CMake.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=j2EDcwI04BSohMxhGry1LMc2Jzxs84rBWyQ7X05lQH8&e=> or in the Programmer's manual. I think the relevant metric here needs to be "which version is available on current LTS distros", and not "how old is the release". The current cmake version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would be happy with a bump to that version, but not something newer. People using other distributions probably have other considerations. If someone wants to perform a cmake version bump, I believe the first step would be to gather what the cmake version availability across distros looks like right now, so an informed decision can be made. I'll actually suggest that we might want to do something else entirely. If we depend on the version available in distros, then we are at the mercy of those distros not updating. It also means that we need to look at several distributions and try to satisfy everybody. That's a lot harder than requiring that people download a recent CMake from cmake.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=VFvTnF8okYQ3GbWeCEjzVIsSw-rvgxPgALVBGP8udME&e=>. CMake has the benefit of being incredibly easy to install, either from source or with the binaries provided on their website. Do you think it's an unreasonable requirement to ask folks to download CMake instead of using the one provided with their OS? Louis -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/dc64b1c3/attachment.html>
Mehdi AMINI via llvm-dev
2020-Mar-28 03:42 UTC
[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi
On Thu, Mar 26, 2020 at 3:14 PM Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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?> 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. > > > > *From:* Shoaib Meenai <smeenai at fb.com> > *Sent:* Thursday, March 26, 2020 2:47 PM > *To:* Chris Tetreault <ctetreau at quicinc.com>; ldionne at apple.com > *Cc:* llvm-dev at lists.llvm.org; Libc++ Dev <libcxx-dev at lists.llvm.org> > *Subject:* [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ > and libc++abi > > > > I understand organization restrictions and old operating systems (I use > CentOS 7 myself), but I’ll note that the only requirement for running a new > CMake is the ability to download and untar a tarball; in particular, you > don’t require sudo. (I understand that there may be restrictions around > running arbitrary executables downloaded from the internet, which of course > make sense, but I wanted to clarify that you don’t need to sudo.) > > > > *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chris > Tetreault via llvm-dev <llvm-dev at lists.llvm.org> > *Reply-To: *Chris Tetreault <ctetreau at quicinc.com> > *Date: *Thursday, March 26, 2020 at 2:06 PM > *To: *"ldionne at apple.com" <ldionne at apple.com> > *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Libc++ Dev < > libcxx-dev at lists.llvm.org> > *Subject: *Re: [llvm-dev] Bumping the CMake requirement for libc++ and > libc++abi > > > > Wanting to use new features is a good reason to upgrade. You say you need > 3.8 in order to compile C++17 code, which is needed by your subproject. > This is a good reason to upgrade the version. The proposed policy of > bumping the CMake minimum version periodically to within some distance of > bleeding edge “just because” is what I object to. We should decide what > cmake features we want to use, justify them to ourselves, and then upgrade > the version to the lowest version that supports the required new features. > We shouldn’t institute a policy of “we upgrade the CMake version to (latest > release – N) every T time interval”. > > > > As for the difficulty of upgrading CMake on a target machine; no amount of > “it’s really easy to do a thing” can make up for “my organization will not > allow me to do a thing.” > > > > *From:* ldionne at apple.com <ldionne at apple.com> > *Sent:* Thursday, March 26, 2020 7:33 AM > *To:* Chris Tetreault <ctetreau at quicinc.com> > *Cc:* Nikita Popov <nikita.ppv at gmail.com>; Libc++ Dev < > libcxx-dev at lists.llvm.org>; llvm-dev at lists.llvm.org > *Subject:* [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ > and libc++abi > > > > > > On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com> wrote: > > > > I would like to just chime in and say that I’m fairly strongly opposed to > any blanket version increases without justification. Having a low version > requirement is a feature. It means that more people can build the codebase. > We should increase the minimum CMake version requirement only if we need to > do so in order to use a new feature. We should be disciplined in deciding > when to use new features if they result in the minimum CMake version being > increased too much. What recent Linux LTS distros ship can help inform > these decisions, but we shouldn’t just upgrade the minimum CMake version to > version X just because Linux distro Y ships that version. > > > > The reason for wanting to upgrade is evidently the use of new features > that would simplify and clean up the build system quite a bit. I can't > speak for other projects, but libc++ and libc++abi are suffering a lot from > the lack of e.g. compile_features in recent CMakes. > > > > > > Anybody who has ever needed to build something on some ancient version of > CentOS because work refuses to upgrade will thank you. > > > > Honestly, CMake is so easy to install that I have a hard time relating: > > > > curl -L > https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.sh > | bash /dev/stdin --skip-license --prefix=<YOUR-INSTALLATION-PREFIX> > > > > This takes about 10 seconds to run and you've got yourself the latest > CMake. I understand how upgrading some tools is difficult, but CMake just > isn't. > > > > Louis > > > > > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Louis > Dionne via llvm-dev > *Sent:* Wednesday, March 25, 2020 10:14 AM > *To:* Nikita Popov <nikita.ppv at gmail.com> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; Libc++ Dev < > libcxx-dev at lists.llvm.org> > *Subject:* [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ > and libc++abi > > > > > > > > > On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com> wrote: > > > > On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 03/25/2020 06:20 AM, Louis Dionne wrote: > > > > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com> wrote: > >> > >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > >>> In October, there was a discussion about updating CMake to 3.15: > http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DOctober_136295.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=2921T7FXA_APW3xYrnSDPuKHRoTGqKh2hoUcUIUalVo&e=>. > No decision was made, but maybe we should revisit that proposal? If we're > going to require a newer version of CMake for some subprojects, I'd prefer > to bump the minimum CMake version for all of LLVM. > > > > My personal opinion is that there's a tendency to view all subprojects > under the LLVM umbrella as a single, monolithic project. That leads to the > desire to make decisions for the whole project, which is often difficult, > as opposed to making the right decision for each subproject, which is often > easier. This results on subprojects being blocked from doing the right > thing for them, like we've seen happen for pre-commit CI. But that's a much > larger (non-technical) discussion than the scope of a simple CMake version > bump. > > > > Let's try to bump CMake for all of LLVM and see how that goes. > > > >> Yes, I agree we should bump the version for all of LLVM, but I don't > >> think we should bump the version without a long-term cmake usage plan. > >> e.g. something like: After every release branch, we bump the cmake > version > >> to whatever version of cmake is X months old. > >> > >> I think the concern that this was our one chance to bump the CMake > version > >> led to the choice of 3.15 as the next version, which would be too new > for some Linux distros. > >> I think if we had a planned upgrade path, it would be easier for those > of us that > >> want something really new to settle on a release that is a little bit > older. > > > > Ok, how about the following policy: > > > > After every release branch, we bump the CMake version to whatever > version of CMake is 12 months old. > > > > This is simple, straightforward, and it gives a full year of old CMakes > being supported. If we did this right now, this would take us to CMake > 3.14.0, released around March 14th, 2019 ( > https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe the > expectation should be that recent CMakes are upgraded using some package > manager or download from the site -- we can't really expect the CMake > version to be the one provided by the system, because that is either > non-existent or very old on most Linux distributions AFAICT. Fortunately, > installing a new CMake is incredibly easy. > > > > Is everybody OK with the above policy? What would be the preferred place > to document it? > > > > 12 months is fine with me. > > I'm not sure the best place to document the policy. Some suggestions are > here: > https://llvm.org/docs/CMake.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_CMake.html&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=j2EDcwI04BSohMxhGry1LMc2Jzxs84rBWyQ7X05lQH8&e=> > or in the Programmer's manual. > > > > I think the relevant metric here needs to be "which version is available > on current LTS distros", and not "how old is the release". The current > cmake version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would > be happy with a bump to that version, but not something newer. People using > other distributions probably have other considerations. If someone wants to > perform a cmake version bump, I believe the first step would be to gather > what the cmake version availability across distros looks like right now, so > an informed decision can be made. > > > > I'll actually suggest that we might want to do something else entirely. If > we depend on the version available in distros, then we are at the mercy of > those distros not updating. It also means that we need to look at several > distributions and try to satisfy everybody. That's a lot harder than > requiring that people download a recent CMake from cmake.org > <https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=YM4mAyT1kPI-ll-X7tbj_u-8Z8VzOQX0UEPWjWpE9XY&s=VFvTnF8okYQ3GbWeCEjzVIsSw-rvgxPgALVBGP8udME&e=> > . > > > > CMake has the benefit of being incredibly easy to install, either from > source or with the binaries provided on their website. Do you think it's an > unreasonable requirement to ask folks to download CMake instead of using > the one provided with their OS? > > > > Louis > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200327/b9ee93cd/attachment.html>