[LLVMdev] [RFC] Raise minimum required CMake version to 3.0

Tobias Grosser tobias at grosser.es
Wed Mar 11 07:31:29 PDT 2015

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?


More information about the llvm-dev mailing list