llvm dev - Feb 2015 - [LLVMdev] [RFC] Raise minimum required CMake version to 3.0

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

-Chris
> 
> Now you may have other good reasons to bump the CMake requirement but it is
not clear from this thread.
> 
> — 
> Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150224/ab27de5d/attachment.html>

> 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
<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/389f956a/attachment.html>

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>