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

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

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

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

Hello,

To me 12 months makes sense - I know that people maintaining distro
packages might disagree. But my view is that it's hard to accommodate
everyone in this regard and it's hard to hold back real needs because of
older distributions.

Both CMake and pip contains up-to-date versions of CMake so installing a
more recent version shouldn't be a problem.

Thanks,
Tobias

On Wed, Mar 25, 2020, 14:21 Louis Dionne via llvm-dev <
llvm-dev at lists.llvm.org> 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?
>
> 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
> >>
> >
>
> _______________________________________________
> 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/ac3e9d7b/attachment.html>

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