Re: (ITS#8483) CMake buildsystem support for LMDB

[hyc@symas.com]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/