I don't think it's such a good idea to install non-default build environment on build VMs, it drives us away from reality. We've just seen the consequences of it when it turned out that we've lost the ability to build the server on pristine precise without even knowing about it. I don't think distributions will be happy if it continues to happen.

If the enterprise server really must not build without the AWS plugin, then maybe we should fork the VM images when the "community" ones are not suitable?

serg: Do you have an opinion on this?

For myself, if it's just cmake that is being updated I'm OK with doing it, but elenst makes a good point about our builders moving away from reality.

I do not personally have any valuable insight about the right thing to do here. We created that AWS key management plugin some time ago, and initially it was only available on EL7. Now it no longer builds there. I don't like that very much, so I'd like to find a solution that allows us to continue to build and distribute this plugin on EL7.

a) Upgrade cmake on the centos7 builder
b) Patch the SDK so that it does not need CMake 2.8.12 (wlad?)
c) Build this plugin elsewhere

You all have much more knowledge than I do of the build process, its restrictions, ramifications of changes, etc., so I'm relying on you all to help decide what to do here.

We stay in reality, as there is still cmake 2.8.9 somewhere else. So if we patch it one tiny version number on a single host, nothing bad will happen, my opinion. It is the easiest thing to do. I'm not sure what was that on pristine precise, but cmake is not a compiler just in case.

If we fork the VM images, I don't mind, just think it is overcautious. Patching AWS sources and maybe contribute back. maybe it is possible, but seriously, 2.8.11 belongs to species that will die out soon.

what about installing newer cmake in $HOME? Then normal server builds will use cmake, while builds with AWS will use $HOME/bin/cmake (or will simply prepend $HOME/bin to path), and everyone will be happy.

sounds like a good idea to me, serg

It's fine by me as well.

cmake 3.7.0 is now in place on the CentOS 7 build VM.

Here are the commands I used to install it:

wget https://cmake.org/files/v3.7/cmake-3.7.0.tar.gz

tar -zxvf cmake-3.7.0.tar.gz

cd cmake-3.7.0

./configure --prefix=/home/buildbot/local

make;make install

And here is how cmake is laid out under /home/buildbot/local/:

[buildbot@centos70-x86-64 ~]$ tree -L 3 ~/local

/home/buildbot/local

├── bin

│   ├── ccmake

│   ├── cmake

│   ├── cpack

│   └── ctest

├── doc

│   └── cmake-3.7

│       ├── cmcompress

│       ├── cmcurl

│       ├── cmlibarchive

│       ├── cmliblzma

│       ├── cmlibuv

│       ├── cmsys

│       ├── cmzlib

│       └── Copyright.txt

└── share

    ├── aclocal

    │   └── cmake.m4

    └── cmake-3.7

        ├── completions

        ├── editors

        ├── Help

        ├── include

        ├── Modules

        └── Templates

BTW: What I've done is an alteration of what serg originally suggested. Instead of installing to $HOME/bin I've installed it to $HOME/local to avoid a common Linux feature of automatically adding $HOME/bin to a user's $PATH if it exists. Such a configuration doesn't exist on the CentOS 7 builder, but it's common enough that I wouldn't rule it out getting added automatically during a future update of the builder, thus the decision to use $HOME/local/bin/ instead.

CMake 3.7.0 installed on vm-centos7-amd64-build VM and buildbot configured so that it is used if the tree is 10.1e or 10.2e. Closing issue.