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

On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> So that we can drop autotools, which currently requires anyone wanting
> to change the build to install an old version of autoconf, among other
> pains. Having two build systems is a way bigger pain than someone
> having to install cmake.
Can you explain why we need to upgrade CMake to drop autotools?

> I still don't see why we should *ever* take the package management
> into consideration if we are OK at all with asking OS X and Windows
> users to manually install something.
It's the nature of Linux package management. I explained a bit on my
previous email.

> In my experience the claim that
> Linux is a more common for development doesn't hold. I personally use
> it on a desktop and OS X on a laptop, but most developers I have seem
> have a mix of Windows and OS X.
Let's not make this a Windows vs Linux more than it already is,
please. We have all three usages, and that's all we should care about.

cheers,
--renato

On 11 March 2015 at 09:45, Renato Golin <renato.golin at linaro.org>
wrote:
> On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> So that we can drop autotools, which currently requires anyone wanting
>> to change the build to install an old version of autoconf, among other
>> pains. Having two build systems is a way bigger pain than someone
>> having to install cmake.
>
> Can you explain why we need to upgrade CMake to drop autotools?
>
>From above in this thread:
---------------------------------------
>From above in this thread:
--------------------------------------------------
I should also point out that CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make
fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of
those bugs are currently blockers to depreciating the autotools build
system.
-------------------------------------------------
------------------------------------------------
>> I still don't see why we should *ever* take the package management
>> into consideration if we are OK at all with asking OS X and Windows
>> users to manually install something.
>
> It's the nature of Linux package management. I explained a bit on my
> previous email.
In other words, it is something specific to the package management
someone choose to use. If we have to support that someone, why don't
we have to support someone else that choose to use Windows or OS X by
dropping cmake completely?

Cheers,
Rafael

On 03/11/2015 03:20 PM, Rafael Espíndola wrote:
> On 11 March 2015 at 09:45, Renato Golin <renato.golin at linaro.org>
wrote:
>> On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>>> So that we can drop autotools, which currently requires anyone
wanting
>>> to change the build to install an old version of autoconf, among
other
>>> pains. Having two build systems is a way bigger pain than someone
>>> having to install cmake.
>>
>> Can you explain why we need to upgrade CMake to drop autotools?
>>
>
>  From above in this thread:
>
> ---------------------------------------
>  From above in this thread:
>
> --------------------------------------------------
> I should also point out that CMAKE_SYSROOT and
> CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make
> fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both
of
> those bugs are currently blockers to depreciating the autotools build
> system.
> -------------------------------------------------
> ------------------------------------------------
>
>>> I still don't see why we should *ever* take the package
management
>>> into consideration if we are OK at all with asking OS X and Windows
>>> users to manually install something.
>>
>> It's the nature of Linux package management. I explained a bit on
my
>> previous email.
>
> In other words, it is something specific to the package management
> someone choose to use. If we have to support that someone, why don't
> we have to support someone else that choose to use Windows or OS X by
> dropping cmake completely?
Can those fixes not just be committed in a way that they are not 
available for older cmake versions, but that instead an error is given 
if people are using these configurations?

Like this the common case still works for Ubuntu LTS as well as most of 
the buildbots and people who need these features are not blocked on old 
cmake versions?

Cheers,
Tobias