[llvm-dev] RFC: Updating to CMake 3.15.0

Tue Oct 29 18:14:19 PDT 2019

On Tue, Oct 29, 2019 at 3:29 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> CMake is extremely easy for developers to download and build locally -- or
> just download binaries for if you like, too.
>

Is there any script we can/would provide to help with this? Or is it so
simple that two lines in the "getting started" instructions would be enough?

-- 
Mehdi

> It's _MUCH_ simpler than upgrading the host C compiler toolchain. Doing
> that can be extremely tricky -- to the point of being nearly impossible for
> all but the most dedicated person. That's the major reason why I think it's
> entirely reasonable to require a new version of cmake, and not at all
> viable to require a new compiler.
>
> As far as distro inclusion -- if LLVM 10 requires CMake 3.15, I have full
> confidence that distros will manage to upgrade CMake first, before pulling
> in LLVM 10. I don't think that'll be a hardship to distro maintainers.
>
> IMO, it will reduce overall pain if we attempt to keep the number of times
> we require a newer cmake as infrequent as we can. And we'll get the most
> benefit if we use the latest release each time we do require such an
> upgrade.
>
> On Tue, Oct 29, 2019 at 3:51 PM David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Oct 29, 2019 at 12:48 PM Jean-Daniel via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> Le 29 oct. 2019 à 19:00, Roman Lebedev via llvm-dev <
>>> llvm-dev at lists.llvm.org> a écrit :
>>>
>>> On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>
>>> +1 to bumping cmake version and cleaning build system somewhat.
>>>
>>> On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>>
>>> On 10/29/2019 10:10 AM, Chris Bieneman via llvm-dev wrote:
>>>
>>> At the LLVM Developer Meeting on October 23rd we held a CMake
>>> roundtable. One of the items we discussed was adopting a more regular
>>> timeline for CMake upgrades. During the roundtable there was overwhelming
>>> support for upgrading CMake, and support for treating CMake differently
>>> than how we treat upgrading host compilers.
>>>
>>> Historically we've taken into account recent versions of Visual Studio,
>>> Xcode and Linux distribution long term support packages when deciding what
>>> CMake version to require. While this does work, it has held us to old
>>> versions of CMake for long periods of time.
>>>
>>> During the roundtable we discussed that the amount of effort involved in
>>> updating to a modern CMake is more or less the same regardless of what
>>> version we choose. We believe this to be true because most OS package
>>> managers have older versions, like the Ubuntu 18.04 LTS which has CMake
>>> 3.10.2 which was released January 18, 2018. Additionally CMake.org
>>> provides binary and source downloads, and building CMake from source has
>>> lower system requirements than LLVM and is very simple.
>>>
>>> With all of this in mind at the roundtable we decided to propose raising
>>> the minimum required CMake version for all LLVM sub-projects to 3.15.0.
>>> Assuming there are no objections to this proposal, I propose a cut-over
>>> date of December 2, 2019.
>>>
>>>
>>> Will users of the CMake export files generated by LLVM also need to use
>>> 3.15.0 or
>>> is it possibly to have the export files require an older version?
>>>
>>> The 10.0 branchpoint will be in early January, I think it would be better
>>> to wait until after the branch.  Mainly because that doesn't give us a
>>> lot of time to actually take advantage of the new features  in 3.15.0
>>> before the
>>> branch, so I don't see much benefit in switching over at that date.
>>>
>>> I think we should also decide on a long-term plan for CMake requirements.
>>> If the conclusion is that users should be able to handle using the latest
>>> (3.15.0) version of CMake, maybe we should just plan to always up-date
>>> to the
>>> latest version in trunk after each release branch is created.
>>>
>>> Would it please be possible to have some reasonably sane
>>> dependency versioning policy?
>>>
>>>
>>>
>>> I'm not sure "sane" captures the nuance of your position - only suggests
>>> that
>>> Tom's suggestion of upgrading to the latest release is "insane"?
>>>
>>> The "insane" word is not in my mail.
>>> I'm only saying it will be good to document the actual versioning policy,
>>> and it will be great if it's not "just manually download XYZ and use it".
>>>
>>> What is it you'd like to avoid or that you find important/valuable about
>>> a one year old
>>> version of CMake, for instance? It means users have to update their CMake
>>> as frequently (since it doesn't skip versions) - but allows some users
>>> to get this
>>> based on their distributions release, rather than having to do it
>>> manually/explicitly?
>>>
>>> Extremely precisely, yes.
>>>
>>> If you require The freshest version of something, it is all but
>>> guaranteed to
>>> be not packaged in distributions, so basically *everyone* will have to
>>> work around the packaging system. If the version is //somewhat// aged,
>>> then it is not unreasonable to expect for it to be present in
>>> //some// proper packaged form in //most// distros.
>>>
>>>
>>> Experience show that distros don’t keep CMake up to date anyway.
>>>
>>
>> Do you have some data on that? It'd be interesting to see what sort of
>> time horizon would help and by how much/little.
>>
>>
>>> So why bother waiting 1 year, as it will most probably not change
>>> anything.
>>>
>>> Moreover, cmake version is only a requirement for LLVM developers
>>> themselves and not LLVM users.
>>>
>>
>> The same argument applies to the host compiler, though - which we've been
>> more cautious about requiring more recent versions of.
>>
>>
>>> It is not uncommon to have to update the installed build tools when
>>> wanting to checkout and build a project, especially one of this size.
>>>
>>>
>>> All that of course does not apply to platforms with no native packaging
>>> system (windows?).
>>>
>>> The exact definition of "aged" will not be precisely definable though,
>>> I would guess 1 year is somewhat around what could be considered
>>> middle-ground.
>>>
>>> Even debian sid only has 3.13.4-1.
>>> How about accepting/requiring version which is at least 1 year old?
>>> That would incidentally, result in requiring cmake v3.13
>>>
>>> -Tom
>>>
>>> Roman
>>>
>>> Thanks,
>>> -Chris
>>> _______________________________________________
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20191029/dbc09074/attachment.html>