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

[Hal Finkel]

----- Original Message -----
> From: "Renato Golin" <renato.golin at linaro.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "jroelofs" <jonathan at codesourcery.com>, "Tobias Grosser" <tobias at grosser.es>,
> "David Chisnall" <David.Chisnall at cl.cam.ac.uk>, "chandlerc" <chandlerc at gmail.com>
> Sent: Wednesday, March 11, 2015 10:20:55 AM
> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0
> 
> On 11 March 2015 at 14:55, Hal Finkel <hfinkel at anl.gov> wrote:
> > I think we should stop fighting about this and ship a version of
> > CMake with LLVM.
> 
> We already manage other unstable dependencies like gcc, glibc,
> binutils, ninja and python (2.7 vs. 3.0). This is even more true on
> non x86 platforms.
> 
> We also have increased the development cost (when not using better
> C++11 alternatives) because some compilers on some platforms were not
> up to the task.
> 
> We have made incremental changes to CMake already (2.8 for now), and
> bumping it again right now would be unwise, IMO.
> 
> Just like we waited MSVC to be mature enough to bump the minimum
> requirement to version 13, I think we should wait for more Linux
> distributions to pick up CMake 3.0 to bump the version up. We have
> used a good pattern for that kind of issue before (with C++11) and it
> worked well in the long run. We should continue the pattern.
> 
> Bundling CMake with LLVM would make builds more complex. It would
> require a bootstrap script (for each platform), so that we can build
> CMake, and we'd need it to be done for all projects. The complexity
> added is not trivial.

Why? CMake itself already has a bootstrap procedure and associated scripts? We'd just defer to those as appropriate. The added complexity is not trivial, but need not be large, and most importantly, is borne by us, not all other users, packagers, systems administrators, etc. Plus, having done so, we'll be in control of what features are available to us, which will provide an offsetting increase in our productivity. Regarding the other dependencies you mentioned, they're mostly providing standardized interfaces (libc, C++11, etc.), except for Python. But Python has lots of optional external dependencies (ncurses, etc.) and would not be a good candidate for shipping inline, plus it's large. CMake's external dependencies are very minimal, and it's not particularly large, making it a much better candidate for bundling.

 -Hal

> 
> cheers,
> --renato
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory