llvm dev - Mar 2020 - Bumping the CMake requirement for libc++ and libc++abi

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. 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.

-Tom
> Cheers,
> Louis
> 
>>> On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>
>>>    Hi,
>>>
>>>    The minimum CMake version currently advertised for libc++ and
libc++abi is currently 3.4.3. I think the oldest version of CMake actually being
tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie
(I'm pretty sure we're using features that require a more recent version
already). However, we do need to bump it to 3.8.0 at least because CMake 3.7
doesn't know about C++17 in its compilation features, and we'll need
that to build libc++ properly going forward. This will mean for bot owners:
>>>    1. They need to upgrade CMake on the builders to at least 3.8.0
(which is really easy), or
>>>    2. they can disable processing of libc++ and libc++abi's
CMake files by making sure they do not appear in LLVM_ENABLE_PROJECTS
>>>
>>>    Any objections?
>>>
>>>    Cheers,
>>>    Louis
>>>
>>>    _______________________________________________
>>>    LLVM Developers mailing list
>>>    llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>

> On Mar 25, 2020, at 12:00, Tom Stellard <tstellar at redhat.com>
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. 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://llvm.org/docs/CMake.html>
or in the Programmer's manual.
Okay, so assuming nobody objects to this, the process would then be:
- I put up a Phabricator review updating the documentation and the
`cmake_minimum_required` fields for (all?) LLVM projects I can find.
- I wait for <some amount of time> before committing the change for build
bot owners to update their CMake
- I commit the change -- at that point using a too-old CMake will error out and
we can point any remaining failing bot to the policy

Does that sound like a reasonable plan? What should be the <some amount of
time>? I'd suggest something like two weeks to give folks ample time to
update builders.

Louis
> 
> -Tom
> 
>> Cheers,
>> Louis
>> 
>>>> On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> 
>>>>   Hi,
>>>> 
>>>>   The minimum CMake version currently advertised for libc++ and
libc++abi is currently 3.4.3. I think the oldest version of CMake actually being
tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie
(I'm pretty sure we're using features that require a more recent version
already). However, we do need to bump it to 3.8.0 at least because CMake 3.7
doesn't know about C++17 in its compilation features, and we'll need
that to build libc++ properly going forward. This will mean for bot owners:
>>>>   1. They need to upgrade CMake on the builders to at least
3.8.0 (which is really easy), or
>>>>   2. they can disable processing of libc++ and libc++abi's
CMake files by making sure they do not appear in LLVM_ENABLE_PROJECTS
>>>> 
>>>>   Any objections?
>>>> 
>>>>   Cheers,
>>>>   Louis
>>>> 
>>>>   _______________________________________________
>>>>   LLVM Developers mailing list
>>>>   llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>   https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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/7d117a2c/attachment.html>

If we're going to be updating the cmake version requirements llvm-wide
(and in particular, if we're going to make a policy out of that), I
think that should be done in a new RFC thread with an appropriate
subject -- people may not notice this discussion because they don't
follow libc++ and ignore any discussions relating to it.

As for the policy itself, I can't say I am fan of automatically bumping
version requirements, just because. A similar idea was proposed when we
were bumping the compiler versions, and was eventually rejected in favor
of the process described at
<https://llvm.org/docs/DeveloperPolicy.html#updating-toolchain-requirements>.
The current process involves proposing a specific version and discussing
the trade-offs implied by it.

Now, bumping the cmake version is not as involved as bumping the
compiler, but maybe it would be good if the process for doing it was
similar? If for nothing else, then for consistency?

regards,
Pavel



On 25/03/2020 17:04, Louis Dionne via llvm-dev wrote:
> 
> 
>> On Mar 25, 2020, at 12:00, Tom Stellard <tstellar at redhat.com
>> <mailto:tstellar at redhat.com>> 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.
> 
> Okay, so assuming nobody objects to this, the process would then be:
> - I put up a Phabricator review updating the documentation and the
> `cmake_minimum_required` fields for (all?) LLVM projects I can find.
> - I wait for <some amount of time> before committing the change for
> build bot owners to update their CMake
> - I commit the change -- at that point using a too-old CMake will error
> out and we can point any remaining failing bot to the policy
> 
> Does that sound like a reasonable plan? What should be the <some amount
> of time>? I'd suggest something like two weeks to give folks ample
time
> to update builders.
> 
> Louis
> 
>>
>> -Tom
>>
>>> Cheers,
>>> Louis
>>>
>>>>> On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev
>>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>> <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>>
>>>>>   Hi,
>>>>>
>>>>>   The minimum CMake version currently advertised for libc++
and
>>>>> libc++abi is currently 3.4.3. I think the oldest version of
CMake
>>>>> actually being tested on any builder is 3.7.0, so
advertising 3.4.3
>>>>> is somewhat of a lie (I'm pretty sure we're using
features that
>>>>> require a more recent version already). However, we do need
to bump
>>>>> it to 3.8.0 at least because CMake 3.7 doesn't know
about C++17 in
>>>>> its compilation features, and we'll need that to build
libc++
>>>>> properly going forward. This will mean for bot owners:
>>>>>   1. They need to upgrade CMake on the builders to at least
3.8.0
>>>>> (which is really easy), or
>>>>>   2. they can disable processing of libc++ and
libc++abi's CMake
>>>>> files by making sure they do not appear in
LLVM_ENABLE_PROJECTS
>>>>>
>>>>>   Any objections?
>>>>>
>>>>>   Cheers,
>>>>>   Louis
>>>>>
>>>>>   _______________________________________________
>>>>>   LLVM Developers mailing list
>>>>>   llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>> <mailto:llvm-dev at lists.llvm.org>
>>>>>   https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On Wed, Mar 25, 2020 at 12:05 PM Louis Dionne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mar 25, 2020, at 12:00, Tom Stellard <tstellar at redhat.com>
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. 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.
>
>
> Okay, so assuming nobody objects to this, the process would then be:
> - I put up a Phabricator review updating the documentation and the
> `cmake_minimum_required` fields for (all?) LLVM projects I can find.
> - I wait for <some amount of time> before committing the change for
build
> bot owners to update their CMake
> - I commit the change -- at that point using a too-old CMake will error
> out and we can point any remaining failing bot to the policy
>
The build compiler and library version updating involved reverting the
change when it is known that bots are failing and recommitting when known
issues are resolved. It may take several rounds to flush everything out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/1d9f83bc/attachment.html>

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. 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.

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/5916c18d/attachment.html>

> 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>

On Wed, Mar 25, 2020 at 12:05 PM Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:
>
>
> On Mar 25, 2020, at 12:00, Tom Stellard <tstellar at redhat.com>
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. 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.
>
>
> Okay, so assuming nobody objects to this, the process would then be:
> - I put up a Phabricator review updating the documentation and the
> `cmake_minimum_required` fields for (all?) LLVM projects I can find.
> - I wait for <some amount of time> before committing the change for
build
> bot owners to update their CMake
> - I commit the change -- at that point using a too-old CMake will error
> out and we can point any remaining failing bot to the policy
>
> Does that sound like a reasonable plan? What should be the <some amount
of
> time>? I'd suggest something like two weeks to give folks ample time
to
> update builders.
>
FWIW, I agree that it's easy to install a non-system cmake and using that
(we do this on all our bots, and it's what people have to do on mac and
windows already)), and that "what is available in LTS distros"
shouldn't
hold things up.

For the actual rollout process, I could imagine that most folks would miss
the phab. So I'd suggest what we've done for similar changes in the
past:

1. Land a change that makes using an older cmake an error that goes like
"We'll require cmake $version soon. You can define
LLVM_SUPPRESS_CMAKE_$version_ERROR to turn this into a warning for a few
weeks, but update your bots soon"

2. Wait 2-4 weeks

3. Make the error unconditional (and remove the wording about the
suppression).

>
> Louis
>
>
> -Tom
>
> Cheers,
> Louis
>
> On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org
> <llvm-dev at lists.llvm.org>>> wrote:
>
>   Hi,
>
>   The minimum CMake version currently advertised for libc++ and libc++abi
> is currently 3.4.3. I think the oldest version of CMake actually being
> tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie
> (I'm pretty sure we're using features that require a more recent
version
> already). However, we do need to bump it to 3.8.0 at least because CMake
> 3.7 doesn't know about C++17 in its compilation features, and we'll
need
> that to build libc++ properly going forward. This will mean for bot owners:
>   1. They need to upgrade CMake on the builders to at least 3.8.0 (which
> is really easy), or
>   2. they can disable processing of libc++ and libc++abi's CMake files
by
> making sure they do not appear in LLVM_ENABLE_PROJECTS
>
>   Any objections?
>
>   Cheers,
>   Louis
>
>   _______________________________________________
>   LLVM Developers mailing list
>   llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org
> <llvm-dev at lists.llvm.org>>
>   https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200326/cf867d61/attachment.html>