[Bf-committers] CMake minimum version increased to 3.0

[Sergey Sharybin]

General consideration:
While from the developers point of view it's not difficult to get newer
CMake to compile Blender it's not something we should force everyone to do.
That being said, all the required libraries versions are in fact as low as
it could be to deliver artists (that's a keyword) new awesome features. In
the case of CMake it's purely developer's maintenance only, nobody else
will see benefit of the version bump.

And one more thing here -- majority of the libraries are optional for
Blender, you can start hacking round with lite version of Blender after
disabling some features. With CMake you can't do it, you'll just be forced
to update the package.

Answer to the install_deps.sh:
You surely can manually compile CMake and put it to /opt, but then you
wouldn't be able to use simplified builds like just typing `make` from the
root folder of the sources. Same actually applies to installing CMake's
official binary packages.

Personal opinion:
Initially i've only checked current Debian stable and it ships CMake-3.0.2
and i thought it's all reasonable since Debian is known to be rather
conservative in all the package versions. But appears Ubuntu which was
known to be more a bleeding edge doesn't have required package. In this
situation i don't think we're in a hurry to do any modifications in the
build systems.


On Tue, Nov 10, 2015 at 10:46 AM, Jeffrey <italic.rendezvous at gmail.com>
wrote:

> The issue is making the dev (or user, like me) jump through hoop after
> hoop just to get it building. It's difficult enough to build and
> troubleshoot your system, but adding new, not-readily-available
> requirements only compounds the problem. By "readily available" I mean a
> package update or additional package in your package manager like yum or
> apt. Then if you have to rebuild a system, or build a new one, you need
> to redo or remember how the system was modified in order to recreate it.
> Granted, install_deps.sh does a pretty good job of getting the required
> libs for blender, but this is a safeguard for building locally only.
> Would it be realistic to provide this automated build method for every
> new lib a new cmake will require?
>
> Then what about cmake-gui? Not everybody can or wants to use the
> terminal to the extent a power user can. You can't use an older version
> of the gui on a new version of cmake, so then you'd have to build the
> gui as well. What else does this mean? Maybe newer library versions than
> your distribution provides. I've had this problem numerous times when
> trying to build less complex software, to the point of not being able to
> or getting too frustrated with the requirements to do it (some
> essentially required a whole rebuild of my system).
>
> The issue is that distros like CentOS, Debian and Ubuntu LTS are built
> to be stable, which inherently means using older, harshly-tested, proven
> software. For example, Fedora 23 is the current version, which is
> approximately three years ahead of CentOS 7, the most recent release.
> How can you support both of these systems when their software versions
> are lightyears apart?
>
> On 11/09/2015 05:45 PM, Howard Trickey wrote:
> >> the issue isn't about Ubuntu 14.10 specifically, its mainly that
> >> someone can have a year-old installation which wouldn't be able to
> >> build Blender (without manually getting CMake at least).
> >>
> >>
> > I was in the situation (Ubuntu with 2.8 CMake); it only took a few
> minutes
> > to download the latest CMake release and put it in a private place and
> fix
> > my PATH to use it.  So maybe this isn't such an onerous requirement.
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> --
> Jeffrey "Italic_" Hoover
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin