Re: [libgpiod PATCH v3] Add cmake support

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Thu, Sep 16, 2021 at 4:27 PM Andreas Pokorny
<andreas.pokorny@xxxxxxxxx> 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