Ivan Shapovalov wrote:
On 2016-08-20 at 03:32 +0100, Howard Chu wrote:
intelfx@intelfx.name wrote:
Full_Name: Ivan Shapovalov Version: LMDB 0.9.18 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch Submission from: (NULL) (77.41.63.43)
This patch adds a CMake buildsystem for LMDB, side-by-side with existing Makefile. It builds the same targets except coverage tests.
I am not a fan of CMake. Using it requires learning a whole new set of documentation in addition to knowing the rules of Make. It comes with a huge footprint of dependencies, and most people using it are misusing it.
Mastering CMake is a lot easier than just learning to use Make...
If you don't like CMake out of personal motives, please just say so
I have said so, right up front: "I am not a fan of CMake."
and don't cover it with made-up reasons.
I don't need to make up reasons. I've spent a lot of time working with CMake already. When setting up a new build environment, it is ridiculously hard to debug a broken setup. Crucial information is hidden, and debug/verbose settings and log files don't reveal it. Been there, done that, no thanks.
If you need to integrate LMDB into a particular CMake-based project, it's a lot simpler than this. E.g., https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib lmdb/CMakeLists.txt
There's no reason to duplicate the entire Makefile when you're embedding LMDB into some other project. This also shows the correct way to use CMake and propagate threads dependencies.
This file does not cover packaging and exporting targets, which is crucial when building multiple dependent projects in a staging tree (e. g. cross-compiling stuff). You see, it is easier to have a single correct build script in the upstream repo than to have many ad-hoc build scripts in each project, each deficient in its own regard.
There is no such thing as a single correct upstream CMake script since different projects have different requirements for how they intend to use their dependencies. Most projects won't need install targets for the utility commands or manpages. Most projects don't need packaging of intermediate dependencies.
There's nothing to argue here. This project doesn't use CMake and we won't maintain files for tools we don't use.