[llvm-dev] RFC: Updating to CMake 3.15.0

Tue Oct 29 12:50:30 PDT 2019

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/f7cbec7d/attachment-0001.html>