llvm dev - Apr 2016 - [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

> On 27 Apr 2016, at 14:47, Renato Golin via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> On 27 April 2016 at 13:42, Bruce Hoult <bruce at hoult.org> wrote:
>> cmake is a big dependency, but it doesn't seem to have many
dependencies
>> itself. They say it's just a C++ compiler and a make (not
necessarily gnu).
>> Probably there are one or two more than that :-)  A shell, for a start;
git
>> or tar/gzip etc.
> 
> It needs a compatible version of C and C++ libraries. If you build on
> a modern machine but run on an older Linux, you'll get at least
> libstdc++ clashes.
It doesn’t link dynamically with libstdc++ and it requires glibc 2.2.5
apparently, from 2002.
They make sure it works on ancient systems when they do a release.
If you want to build a bleeding edge compiler on a system from 2002, you may
have bigger issues
than trying to run CMake.
> 
> Also, compiling CMake and Ninja is not the most reliable way of
> deploying buildbots.
Ninja is not the problem here though and I would agree that it’s not reliable.
Fortunately, CMake can generate projects compatible with quite old versions of
Make already.
> 
> What's wrong with using newer CMake features IFF you have that
> version? Then you can choose where to incur the extra deployment cost
> or not based on your need of that feature.
Maintenance burden.
Few people will understand why there’s 2 code paths in the build script and will
duplicate the wrong
one when creating a new module and looking for “inspiration".
> 
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
/Florent

On 27 April 2016 at 15:28, Florent Castelli <florent.castelli at
gmail.com> wrote:
> If you want to build a bleeding edge compiler on a system from 2002, you
may have bigger issues
> than trying to run CMake.
If you're cross compiling, you have less of a choice over what's on
the target and host.

> Maintenance burden.
> Few people will understand why there’s 2 code paths in the build script and
will duplicate the wrong
> one when creating a new module and looking for “inspiration".
That would be quickly caught by buildbots. We deal with that issue already.

To be clear, I'm not against moving the version up, I just want to
make sure that people understand that this is not *just* a version
upgrade, but a development philosophy move for all Linux developers
and production environments (of which we have plenty). This move was
proposed before and was rejected for the reasons I pointed out:
maintenance.

Once we go the path of accepting compiled versions of CMake, then
anyone will be able to add any feature and put the maintenance burden
on who had nothing to do with it, ie, production environment
maintainers. Having a cap on CMake/Ninja has the great advantage that
production environments will remain stable for as long as possible and
I can plan my migrations.

So far, the argument for a new CMake is that it's "nicer", not
that it
has a feature that we cannot go without, and that's not strong enough,
especially when against increased production environment maintenance
cost.

--renato

> To be clear, I'm not against moving the version up, I just want to
> make sure that people understand that this is not *just* a version
> upgrade, but a development philosophy move for all Linux developers
> and production environments (of which we have plenty). This move was
> proposed before and was rejected for the reasons I pointed out:
> maintenance.
Yes. It is a move to put linux developers in the same position as
windows and OS X ones, which is a *very* reasonable thing to do.

Cheers,
Rafael