llvm dev - Mar 2020 - 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 <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
<http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html>. 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
<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://llvm.org/docs/CMake.html>
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.

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/20200325/ff325ff8/attachment.html>

This repeats a discussion from late last year and tends to revolve 
around a philosophy of how software distribution should be done and the 
cmake issue has brought that into focus. We may be able to glide past 
this issue with the Ubuntu 20.04 LTS version due shortly and then save 
the cmake issue for another day if it later needs to be revived.

Neil Nelson

On 3/25/20 11:14 AM, Louis Dionne via llvm-dev wrote:
>
>
>> 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.
>>     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.htmlor 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 <http://cmake.org>.
>
> 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/20200325/cae7b067/attachment-0001.html>

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.

Anybody who has ever needed to build something on some ancient version of CentOS
because work refuses to upgrade will thank you.


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<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. 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 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<http://cmake.org>.

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/20200325/82e1c6aa/attachment.html>

> 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
<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
<http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html>. 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
<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://llvm.org/docs/CMake.html>
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
<http://cmake.org/>.
>  
> 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/70a347d9/attachment.html>