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>
James Y Knight via llvm-dev
2019-Oct-29 22:28 UTC
[llvm-dev] RFC: Updating to CMake 3.15.0
CMake is extremely easy for developers to download and build locally -- or just download binaries for if you like, too. 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/7cd07531/attachment.html>
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>