You might like this script that wraps cmake in a configure-like interface [1].
Also, CMAKE_INSTALL_PREFIX vs. --prefix is just different magical incantations. The obvious is sometimes what you are most used to.
CMake do provide a UI of sorts for exploring the various options. You have to run cmake . once first to get the defaults generated, and then you can use ccmake . to get a UI.
I find its insistence on all caps everywhere to be a bit of a annoyance though. But it guess it inherits that from make.
I'm familiar with autoconf's configure options like --prefix and variables like CXXFLAGS, and if not I can see a reasonably short listing and explanation of them with `./configure --help`, and that list often includes other --enable-foo like options the project defined.
CMake, on the other hand, does not (at least for the projects I've run into?) honor --prefix or CXXFLAGS as arguments to cmake, and cmake --help doesn't show what variables it does honor. Through googling and cargo-culting I've come up with some more cryptic replacements - `-DCMAKE_INSTALL_PREFIX:PATH=$PREFIX`, `-DCMAKE_CXX_FLAGS="-lrt"`.
Now that I look at the `cmake --help` output again, I notice that in the middle of its long list of unhelpful output, there's mention of `--help-properties` and `--help-variables`, but the output is super long.
Finally, I've seen indications that cmake is a huge pain if you want to add some custom targets and rules that it doesn't generate automatically for common languages in common layouts: https://samthursfield.wordpress.com/2015/11/21/cmake-depende...
I'm not a huge fan of autotools either, I tend to just write Makefiles directly (and not make any attempt at portability to Windows). It's actually not hard to correctly handle parallel, cross-platform, and cross-compiling support, just for linux / os x / bsd. It's a lot easier than fixing a cmake or autotools project that apparently messed something up in their configuration ...