Chris Bieneman
2015-Feb-24 22:21 UTC
[LLVMdev] [RFC] Raise minimum required CMake version to 3.0
My list of useful features in newer CMake versions, that I would like to see used: CMake 2.8.10 * INTERFACE_LIBRARY (we already use this by hacking around the CMake version) CMake 2.8.11 * Targets can now have dependencies that are arbitrary files instead of just link dependencies (http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements <http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements>) * target_include_directories command (allows us to cleanup our code) * target_compile_definitions command (allows us to cleanup our code) * More updates to the Interface library features CMake 2.8.12 * New ALIAS targets * CMAKE_CONFIGURATION_TYPES variable is defined in multi-config generators (we already use this) * XCODE_ATTRIBUTE_* might be nice for our Xcode users… * cmake_reset_check_state - would be handy for anyone doing development against changing target operating systems CMake 3.0 * CMAKE_SYSROOT * CMAKE_<LANG>_COMPILER_TARGET would be useful for cross-compiling Aside from this there are lots of fixes and changes around the export() and install(EXPORT) commands that should make cross-compiling better. Like I said, I actually don’t care that much about the move to 2.8.12.2, but I care very strongly about us not being tied to the “stable” version of <insert Linux distro>, which may or may not update frequently. I’m not thrilled about tying ourselves to Ubuntu, but they at least ship LTS releases every two years. Debian release cycles are less predictable, and WAY more out of date. -Chris> On Feb 24, 2015, at 12:09 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Feb 24, 2015, at 11:56 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> >>> >>> On Feb 24, 2015, at 11:13 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> >>>> >>>> On Feb 24, 2015, at 9:33 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>> >>>>> >>>>> On Feb 24, 2015, at 8:45 AM, Tobias Grosser <tobias at grosser.es <mailto:tobias at grosser.es>> wrote: >>>>> >>>>> On 09.02.2015 20:12, Chris Bieneman wrote: >>>>>> It came up on another thread that our current minimum required CMake version 2.8.8, has some bugs that cause issues when building with MSVC + Ninja, and one potential solution was to raise the minimum required version of CMake. >>>>>> >>>>>> CMake 3.0 is now 6 months old and CMake 3.1 has been released. I would like to propose moving our minimum required CMake version to 3.0. >>>>>> >>>>>> I’ve attached patches to enforce the change in case anyone wants to test it out. >>>>>> >>>>>> Thoughts/comments/concerns/objections? >>>>> >>>>> Hi Chris, >>>>> >>>>> this update broke my cmake LLVM+Polly buildbot (to my knowledge most other bots use autoconf). I reverted this temporarily to avoid the buildbot noise (this comes a little late, as I was traveling the last days). >>>> >>>> Actually at this point I think most bots are on CMake. The green dragon bots are all CMake, Galina and Takumi’s bots are at least partially on CMake. >>>> >>>>> >>>>> The buildbot is based on the latest debian stable (wheezy), which comes with cmake 2.8.9. Is 2.8.9 enough to fix the bug? >>>> >>>> No. The bug requires 2.8.12.1. I really wanted 3.0, but Chandler requested 2.8.12.2 because it was the version in the latest Ubuntu LTS. >>>> >>>> I’m going to put on my “unpopular opinion” hat for a second. I don’t think it is reasonable for us to limit our CMake version to the lowest common denominator of all Linux distributions. I really think the Linux developers should just do what I do on OS X and build it from source. Building CMake is really simple and fast. >>>> >>>> This is kinda a bit of a sore point for me because it turns out that our CMake goop for cross-compiling is pretty nasty, and there are features in CMake 3.x that make it a lot better. Unfortunately using the new features while supporting CMake 2.8.x would only make our goop goopier. >>> >>> How does raising from 2.8.9 to 2.8.12.1 helps? It won’t bring the 3.x features that you’d like to have. >>> >>> As I understood it, bumping the version to 2.8.12.1 is motivated by a bug related to "MSVC + Ninja” (http://www.cmake.org/Bug/view.php?id=14492 <http://www.cmake.org/Bug/view.php?id=14492> ) >> >> Raising CMake 2.8.12.x allows us to remove a bunch of crufty hacks to support older versions, and it gets some critical bug fixes for Visual Studio and Xcode generators (like support for Xcode 5). >> There are a lot of features in 2.8.10, 2.8.11 and 2.8.12 that would be nice to have too. >> >>> >>> If this is indeed a bug in CMake that affects one very specific platform/configuration, I don’t see this alone as a justification to raise the requirement for all the platform. >>> It is up to the user of the platform not to use a CMake version that is buggy for their platform/configuration. >> >> I actually think we should establish a policy for updating the minimum required version of CMake similar to how we update minimum required compiler versions. That will allow us to take advantage of the fact that the CMake team makes rapid progress without carrying a lot of baggage for maintaining compatibility of older versions. >> >> For context. CMake 2.8.9 was released in 8/2012, 2.8.12 was released 11/2013, 3.0 was released 6/2014, and 3.1 was released 12/2014. >> >> I suspect that supporting 2 releases back (like we do for VS) probably isn’t sufficient because that’s only about 6 months, but I think supporting back to 2012 is a bit much for CMake because the project is moving really quickly. > > I agree that the same approach should be taken as for the compiler version, i.e. cost/benefit analysis. > > The commit that was reverted alone does not show significant benefits in our CMake configuration files (10 lines removed to handle CMP0022 basically). > You are mentioning “a lot of features” that would be nice to have in 2.8.10/11/12. > What are these features and how/when do you plan to take advantage of these features? > If there is no short-term (next 6 months) plan to improve/extend our CMake infrastructure with these features, then this change can wait till then. > > Thanks, > > Mehdi-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/bcb6376d/attachment.html>
Tobias Grosser
2015-Feb-25 00:36 UTC
[LLVMdev] [RFC] Raise minimum required CMake version to 3.0
Hi Chris, I meanwhile updated cmake on my buildbot to 3.2 to make sure this individual bot does not block the update. I really do not want to block progress, but agree with Mehdi that we should be a little careful with increasing the minimal cmake version. If you believe the cost is understood and there is an important feature that requires us to pay this cost, I will not block this version increase (even though I do not see this feature up to 2.8.12). @Sylvestre: Would an update to cmake 2.8.12.2 make it harder for you to switch your wheezy package builds to cmake? On 24.02.2015 23:21, Chris Bieneman wrote:> My list of useful features in newer CMake versions, that I would like to > see used:[...]> Like I said, I actually don’t care that much about the move to 2.8.12.2, > but I care very strongly about us not being tied to the “stable” version > of <insert Linux distro>, which may or may not update frequently. I’m > not thrilled about tying ourselves to Ubuntu, but they at least ship LTS > releases every two years. Debian release cycles are less predictable, > and WAY more out of date.Debian had (with one exception) a two year release cycle similar to Ubuntu: https://wiki.debian.org/DebianReleases#Release_statistics At the moment we are very close to the next stable release which seems to be expected somewhere in March/April this year. It will ship with cmake 3.x. Cheers, Tobias P.S: http://llvm.org/docs/CMake.html needs updating when you change the cmake version.
Zachary Turner
2015-Feb-25 05:59 UTC
[LLVMdev] [RFC] Raise minimum required CMake version to 3.0
Speaking of new versions of CMake and new features that we should use more, I would really like to see the static library build move to CMake OBJECT libraries <http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library> Object libraries were introduced in CMake 2.8.8. We had a discussion about this over lunch today, and I believe this conversion should be possible and provide benefits for every platform. An object library, if you're not familiar, is a library which produces no archive, has no link interface, and you do not link against it with target_link_libraries. Instead, you link against it by including it as a *source* in the sources list when calling add_library(), which causes CMake to change the way it builds the command line to the linker. Instead of passing a single archive to the linker, it instead passes every single object file separately to the linker. There are a lot of benefits to using object libraries, but the most poignant benefit I can point to is on Windows, since that's the platform I know the most about. **Incremental Linking is disabled with MSVC when you link against a library file <https://msdn.microsoft.com/en-us/library/024awkd1.aspx>.** Thus, if everything were an object library, our link times would be massively improved. Probably an order of magnitude. Of course, to do this will be a lot of work on the CMake side. And we will need to either deal with CMP0051 <http://www.cmake.org/cmake/help/v3.1/policy/CMP0051.html> or disable the policy. I actually submitted a patch earlier today to disable this policy because I needed an object library to solve an actual serious problem, and an object library was the only way. But just a warning in case we go down this path. On Tue, Feb 24, 2015 at 2:27 PM Chris Bieneman <beanz at apple.com> wrote:> My list of useful features in newer CMake versions, that I would like to > see used: > > CMake 2.8.10 > * INTERFACE_LIBRARY (we already use this by hacking around the CMake > version) > > CMake 2.8.11 > * Targets can now have dependencies that are arbitrary files instead of > just link dependencies ( > http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements) > * target_include_directories command (allows us to cleanup our code) > * target_compile_definitions command (allows us to cleanup our code) > * More updates to the Interface library features > > CMake 2.8.12 > * New ALIAS targets > * CMAKE_CONFIGURATION_TYPES variable is defined in multi-config generators > (we already use this) > * XCODE_ATTRIBUTE_* might be nice for our Xcode users… > * cmake_reset_check_state - would be handy for anyone doing development > against changing target operating systems > > CMake 3.0 > * CMAKE_SYSROOT > * CMAKE_<LANG>_COMPILER_TARGET would be useful for cross-compiling > > Aside from this there are lots of fixes and changes around the export() > and install(EXPORT) commands that should make cross-compiling better. > > Like I said, I actually don’t care that much about the move to 2.8.12.2, > but I care very strongly about us not being tied to the “stable” version of > <insert Linux distro>, which may or may not update frequently. I’m not > thrilled about tying ourselves to Ubuntu, but they at least ship LTS > releases every two years. Debian release cycles are less predictable, and > WAY more out of date. > > -Chris > > On Feb 24, 2015, at 12:09 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 24, 2015, at 11:56 AM, Chris Bieneman <beanz at apple.com> wrote: > > > On Feb 24, 2015, at 11:13 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 24, 2015, at 9:33 AM, Chris Bieneman <beanz at apple.com> wrote: > > > On Feb 24, 2015, at 8:45 AM, Tobias Grosser <tobias at grosser.es> wrote: > > On 09.02.2015 20:12, Chris Bieneman wrote: > > It came up on another thread that our current minimum required CMake > version 2.8.8, has some bugs that cause issues when building with MSVC + > Ninja, and one potential solution was to raise the minimum required version > of CMake. > > CMake 3.0 is now 6 months old and CMake 3.1 has been released. I would > like to propose moving our minimum required CMake version to 3.0. > > I’ve attached patches to enforce the change in case anyone wants to test > it out. > > Thoughts/comments/concerns/objections? > > > Hi Chris, > > this update broke my cmake LLVM+Polly buildbot (to my knowledge most other > bots use autoconf). I reverted this temporarily to avoid the buildbot noise > (this comes a little late, as I was traveling the last days). > > > Actually at this point I think most bots are on CMake. The green dragon > bots are all CMake, Galina and Takumi’s bots are at least partially on > CMake. > > > The buildbot is based on the latest debian stable (wheezy), which comes > with cmake 2.8.9. Is 2.8.9 enough to fix the bug? > > > No. The bug requires 2.8.12.1. I really wanted 3.0, but Chandler requested > 2.8.12.2 because it was the version in the latest Ubuntu LTS. > > I’m going to put on my “unpopular opinion” hat for a second. I don’t think > it is reasonable for us to limit our CMake version to the lowest common > denominator of all Linux distributions. I really think the Linux developers > should just do what I do on OS X and build it from source. Building CMake > is really simple and fast. > > This is kinda a bit of a sore point for me because it turns out that our > CMake goop for cross-compiling is pretty nasty, and there are features in > CMake 3.x that make it a lot better. Unfortunately using the new features > while supporting CMake 2.8.x would only make our goop goopier. > > > How does raising from 2.8.9 to 2.8.12.1 helps? It won’t bring the 3.x > features that you’d like to have. > > As I understood it, bumping the version to 2.8.12.1 is motivated by a bug > related to "MSVC + Ninja” (http://www.cmake.org/Bug/view.php?id=14492 ) > > > Raising CMake 2.8.12.x allows us to remove a bunch of crufty hacks to > support older versions, and it gets some critical bug fixes for Visual > Studio and Xcode generators (like support for Xcode 5). > > There are a lot of features in 2.8.10, 2.8.11 and 2.8.12 that would be > nice to have too. > > > If this is indeed a bug in CMake that affects one very specific > platform/configuration, I don’t see this alone as a justification to raise > the requirement for all the platform. > It is up to the user of the platform not to use a CMake version that is > buggy for their platform/configuration. > > > I actually think we should establish a policy for updating the minimum > required version of CMake similar to how we update minimum required > compiler versions. That will allow us to take advantage of the fact that > the CMake team makes rapid progress without carrying a lot of baggage for > maintaining compatibility of older versions. > > For context. CMake 2.8.9 was released in 8/2012, 2.8.12 was released > 11/2013, 3.0 was released 6/2014, and 3.1 was released 12/2014. > > I suspect that supporting 2 releases back (like we do for VS) probably > isn’t sufficient because that’s only about 6 months, but I think supporting > back to 2012 is a bit much for CMake because the project is moving really > quickly. > > > I agree that the same approach should be taken as for the compiler > version, i.e. cost/benefit analysis. > > The commit that was reverted alone does not show significant benefits in > our CMake configuration files (10 lines removed to handle CMP0022 > basically). > You are mentioning “a lot of features” that would be nice to have in > 2.8.10/11/12. > What are these features and how/when do you plan to take advantage of > these features? > If there is no short-term (next 6 months) plan to improve/extend our CMake > infrastructure with these features, then this change can wait till then. > > Thanks, > > Mehdi > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/a5679ecc/attachment.html>
Owen Anderson
2015-Feb-25 17:49 UTC
[LLVMdev] [RFC] Raise minimum required CMake version to 3.0
This seems like a non-starter for projects that use LLVM as a library… —Owen> On Feb 24, 2015, at 9:59 PM, Zachary Turner <zturner at google.com> wrote: > > Speaking of new versions of CMake and new features that we should use more, I would really like to see the static library build move to CMake OBJECT libraries <http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library> > > Object libraries were introduced in CMake 2.8.8. We had a discussion about this over lunch today, and I believe this conversion should be possible and provide benefits for every platform. An object library, if you're not familiar, is a library which produces no archive, has no link interface, and you do not link against it with target_link_libraries. Instead, you link against it by including it as a *source* in the sources list when calling add_library(), which causes CMake to change the way it builds the command line to the linker. Instead of passing a single archive to the linker, it instead passes every single object file separately to the linker. > > There are a lot of benefits to using object libraries, but the most poignant benefit I can point to is on Windows, since that's the platform I know the most about. **Incremental Linking is disabled with MSVC when you link against a library file <https://msdn.microsoft.com/en-us/library/024awkd1.aspx>.** Thus, if everything were an object library, our link times would be massively improved. Probably an order of magnitude. > > Of course, to do this will be a lot of work on the CMake side. And we will need to either deal with CMP0051 <http://www.cmake.org/cmake/help/v3.1/policy/CMP0051.html> or disable the policy. I actually submitted a patch earlier today to disable this policy because I needed an object library to solve an actual serious problem, and an object library was the only way. But just a warning in case we go down this path. > > > > On Tue, Feb 24, 2015 at 2:27 PM Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > My list of useful features in newer CMake versions, that I would like to see used: > > CMake 2.8.10 > * INTERFACE_LIBRARY (we already use this by hacking around the CMake version) > > CMake 2.8.11 > * Targets can now have dependencies that are arbitrary files instead of just link dependencies (http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements <http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements>) > * target_include_directories command (allows us to cleanup our code) > * target_compile_definitions command (allows us to cleanup our code) > * More updates to the Interface library features > > CMake 2.8.12 > * New ALIAS targets > * CMAKE_CONFIGURATION_TYPES variable is defined in multi-config generators (we already use this) > * XCODE_ATTRIBUTE_* might be nice for our Xcode users… > * cmake_reset_check_state - would be handy for anyone doing development against changing target operating systems > > CMake 3.0 > * CMAKE_SYSROOT > * CMAKE_<LANG>_COMPILER_TARGET would be useful for cross-compiling > > Aside from this there are lots of fixes and changes around the export() and install(EXPORT) commands that should make cross-compiling better. > > Like I said, I actually don’t care that much about the move to 2.8.12.2, but I care very strongly about us not being tied to the “stable” version of <insert Linux distro>, which may or may not update frequently. I’m not thrilled about tying ourselves to Ubuntu, but they at least ship LTS releases every two years. Debian release cycles are less predictable, and WAY more out of date. > > -Chris > >> On Feb 24, 2015, at 12:09 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> >>> >>> On Feb 24, 2015, at 11:56 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>> >>>> >>>> On Feb 24, 2015, at 11:13 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>>> >>>>> >>>>> On Feb 24, 2015, at 9:33 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>>> >>>>>> >>>>>> On Feb 24, 2015, at 8:45 AM, Tobias Grosser <tobias at grosser.es <mailto:tobias at grosser.es>> wrote: >>>>>> >>>>>> On 09.02.2015 20:12, Chris Bieneman wrote: >>>>>>> It came up on another thread that our current minimum required CMake version 2.8.8, has some bugs that cause issues when building with MSVC + Ninja, and one potential solution was to raise the minimum required version of CMake. >>>>>>> >>>>>>> CMake 3.0 is now 6 months old and CMake 3.1 has been released. I would like to propose moving our minimum required CMake version to 3.0. >>>>>>> >>>>>>> I’ve attached patches to enforce the change in case anyone wants to test it out. >>>>>>> >>>>>>> Thoughts/comments/concerns/objections? >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> this update broke my cmake LLVM+Polly buildbot (to my knowledge most other bots use autoconf). I reverted this temporarily to avoid the buildbot noise (this comes a little late, as I was traveling the last days). >>>>> >>>>> Actually at this point I think most bots are on CMake. The green dragon bots are all CMake, Galina and Takumi’s bots are at least partially on CMake. >>>>> >>>>>> >>>>>> The buildbot is based on the latest debian stable (wheezy), which comes with cmake 2.8.9. Is 2.8.9 enough to fix the bug? >>>>> >>>>> No. The bug requires 2.8.12.1. I really wanted 3.0, but Chandler requested 2.8.12.2 because it was the version in the latest Ubuntu LTS. >>>>> >>>>> I’m going to put on my “unpopular opinion” hat for a second. I don’t think it is reasonable for us to limit our CMake version to the lowest common denominator of all Linux distributions. I really think the Linux developers should just do what I do on OS X and build it from source. Building CMake is really simple and fast. >>>>> >>>>> This is kinda a bit of a sore point for me because it turns out that our CMake goop for cross-compiling is pretty nasty, and there are features in CMake 3.x that make it a lot better. Unfortunately using the new features while supporting CMake 2.8.x would only make our goop goopier. >>>> >>>> How does raising from 2.8.9 to 2.8.12.1 helps? It won’t bring the 3.x features that you’d like to have. >>>> >>>> As I understood it, bumping the version to 2.8.12.1 is motivated by a bug related to "MSVC + Ninja” (http://www.cmake.org/Bug/view.php?id=14492 <http://www.cmake.org/Bug/view.php?id=14492> ) >>> >>> Raising CMake 2.8.12.x allows us to remove a bunch of crufty hacks to support older versions, and it gets some critical bug fixes for Visual Studio and Xcode generators (like support for Xcode 5). >>> There are a lot of features in 2.8.10, 2.8.11 and 2.8.12 that would be nice to have too. >>> >>>> >>>> If this is indeed a bug in CMake that affects one very specific platform/configuration, I don’t see this alone as a justification to raise the requirement for all the platform. >>>> It is up to the user of the platform not to use a CMake version that is buggy for their platform/configuration. >>> >>> I actually think we should establish a policy for updating the minimum required version of CMake similar to how we update minimum required compiler versions. That will allow us to take advantage of the fact that the CMake team makes rapid progress without carrying a lot of baggage for maintaining compatibility of older versions. >>> >>> For context. CMake 2.8.9 was released in 8/2012, 2.8.12 was released 11/2013, 3.0 was released 6/2014, and 3.1 was released 12/2014. >>> >>> I suspect that supporting 2 releases back (like we do for VS) probably isn’t sufficient because that’s only about 6 months, but I think supporting back to 2012 is a bit much for CMake because the project is moving really quickly. >> >> I agree that the same approach should be taken as for the compiler version, i.e. cost/benefit analysis. >> >> The commit that was reverted alone does not show significant benefits in our CMake configuration files (10 lines removed to handle CMP0022 basically). >> You are mentioning “a lot of features” that would be nice to have in 2.8.10/11/12. >> What are these features and how/when do you plan to take advantage of these features? >> If there is no short-term (next 6 months) plan to improve/extend our CMake infrastructure with these features, then this change can wait till then. >> >> Thanks, >> >> Mehdi > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150225/f32921a5/attachment.html>