Dropping autoconf support

[sergiud]

Currently, glog supports three build systems: autoconf, CMake, and bazel. As autoconf scripts are not actively maintained and CMake can be used as a replacement, I suggest we drop the autoconf support altogether. This would particularly reduce the effort for maintaining the compatibility between autonconf and CMake (and maybe bazel?) scripts.

/cc @ukai @drigz @shinh

[drigz]

The Bazel build templates the headers based on templates like config.h.cmake.in, logging.h.in, etc. Would these change? For example, logging.h.in refers to @ac_google_end_namespace@ etc - would these be removed / replaced by CMake templates?

If the answer is no, then I think this wouldn't affect the Bazel build. If yes, it should be fairly easy to update the sed duct tape that handles the templating when building with Bazel.

[sergiud]

Thanks for the info. I thought of keeping placeholder names as is at first. But after seeing the script, we can also update the names to something more readable.

[shinh]

+1. I was a bit worried this decision may confuse distributions like Debian, however, since I realized gflags has already dropped autotools support, now I'm feeling it's OK.

[Flamefire]

For example, logging.h.in refers to @ac_google_end_namespace@ etc - would these be removed / replaced by CMake templates?

Note that @name@ is a perfectly valid template for cmake (configure_file) and even better than the alternative. See @ONLY in the documentation