cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BLAH -DCMAKE_FOO -DCMAKE_WHO_KNOWS_WHAT:PATH=/opt/myssl
Guess what, on older cmake versions this list did not include anything older that 3.3, so it was failing with in-comprehensive generic "not found" error even though 3.4 was installed.
With this "fix" somebody somewhere will be banging their head against the wall again once 3.8 is out.
Overall, when things go wrong debugging cmake requires cmake knowledge, while autotools mostly require shell knowledge which is much more common (again, for sysadmins/packagers).
So while cmake is better for developers it is usually worse off for packagers and advanced users. I'm not saying migration is not worth it, I'm pointing out costs of such migration.
PS: I personally like Google's internal version of
https://bazel.build/ a lot. I've never used open-source version but I presume it's similar. While it has many problems (Java, lack of popular IDE support, lack of popularity and, again, Java) good parts are rules are both machine- and human- readable and writable and generally easy to debug. I'm not bold enough to propose PostgreSQL to use it, but I'd be happy to see ideas from it to be used elsewhere.
