On Thu, Sep 16, 2021 at 4:27 PM Andreas Pokorny
[off-list ref] wrote:

This is a wip cmake support for libgpiod. It allows to integrate
libgpiod as part of a bigger cmake project built via the new package
management feature of cmake called FetchContent or as git submodule.
This work is motivated by the fact that not all distributions offer
proper development packages with bindings enabled and for the different
kernel api versions of gpio. This change can be provided/used as an
external build script, or conveniently shipped with libgpiod if desired.
Both ways I felt the urge to share it with upstream and potential users.

It does offer various build options to control whether tests, C++
bindings, tools, python bindings or examples are built. Furthermore
you can control if the libraries are built as archives or shared
libraries. Basic install support is available.

The options are:
 * GPIOD_TOOLS_ENABLED (OFF)
 * GPIOD_TESTS_ENABLED (OFF)
 * GPIOD_CXX_BINDINGS_ENABLED (ON)
 * GPIOD_PYTHON_BINDINGS_ENABLED (ON)
 * GPIOD_EXAMPLES_ENABLED (OFF)

This change is still wip, not everything works well enough:
 * examples are not built
 * tests are built but not integrated properly
 * install location of the python module is still incorrect
 * man page generation is missing
---

Hi! Thanks for the patch.

I'm not sure having two build systems in parallel is a good idea
frankly. Whenever we add a new file or rearrange anything we'd need to
remember to change it in both systems. This is the same issue I had
with meson except that meson is more modern and I would consider it as
a replacement of autotools first before cmake.

Why is that needed anyway? Doesn't CMake support pkgconfig? I would
like to learn more about the reasoning.

Bart