[Date Prev][Date Next]
Re: (ITS#8483) CMake buildsystem support for LMDB
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8483) CMake buildsystem support for LMDB
- From: email@example.com
- Date: Sat, 20 Aug 2016 03:03:59 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Ivan Shapovalov wrote:
> On 2016-08-20 at 03:32 +0100, Howard Chu wrote:
>> firstname.lastname@example.org 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) (188.8.131.52)
>>> This patch adds a CMake buildsystem for LMDB, side-by-side with
>>> It builds the same targets except coverage tests.
>> I am not a fan of CMake. Using it requires learning a whole new set
>> 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.,
>> 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
>> 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
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/