The way Python bindings are built has changed and the information in the
README file is now outdated. Remove the no longer valid bits and - while
at it - point the readers to sub-READMEs for Python and Rust bindings.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Major version 2 of libgpiod requires linux kernel uAPI v2 to be available.
This was released in Linux 5.10 so mention it in the README.
Suggested-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
BATS has been confirmed to run much more slowly that shunit2. This is
most likely caused by the way BATS evaluates each test file n+1 times
where n is the number of tests[1].
Port tests to using shunit2 which executes as a regular shell script
which, in addition to higher speed, allows for easier debugging as
standard shell flags like -x now work.
[1] https://bats-core.readthedocs.io/en/stable/writing-tests.html
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Kent Gibson <warthog618@gmail.com>
This change replaces building against "bundled" headers by always
building agains system headers (while following standard conventions to
allow users to specify the version to build against).
Reasoning:
Previously, the code generated the bindings based on the headers, but
then links against `-lgpiod` without further specifying where that is
coming from.
This results in some challenges and problems:
1. Packaging a Rust crate with `cargo package` requires the folder
containing the Cargo.toml to be self-contained. Essentially, a tar
ball with all the sources of that folder is created. Building against
that tar ball fails, since the headers files passed to bindgen are
a relative path pointing outside of that folder.
2. While, for example, the cxx bindings are built AND linked against
the build results, the packaging situation for C++ libraries is a
bit different compared to Rust libs. The C++ libs will likely get
built as part of the larger libgpiod build and published together
with the C variant.
In Rust, the vast majority of people will want to build the glue-code
during the compilation of the applications that consume this lib.
This may lead to inconsistencies between the bundled headers and the
libraries shipped by the user's distro. While ABI should hopefully
be forward-compatible within the same MAJOR number of the .so,
using too new headers will likely quickly lead to mismatches with
symbols defined in the lib.
3. Trying to build the core lib as part of the Rust build quickly runs
into similar packaging issues as the existing solution. The source
code of the C lib would need to become part of some package
(often people opt to pull it in as a submodule under their -sys crate
or even create a separate -src package [1]). This clearly does not
work well with the current setup...
Since building against system libs is probably? what 90%+ of the people
want, this change hopefully addresses the problems above. The
system-deps dependency honors pkg-config conventions, but also allows
users flexible ways to override the defaults [2]. Overall, this keeps
things simple while still allowing maximum flexibility.
Since the pkg-config interface is just telling us which include paths to
use, we switch back to a wrapper.h file that includes the real gpiod.h.
Once Rust bindings require a lower version floor, the version metadata
can also be updated to help telling users that their system library is
too old.
In order to support people hacking on the Rust bindings, building with
make will automatically set the right set of environment variables.
In case people want to customize it when building without `make`, a
reference to the system_deps documentation is given in the README.md.
[1] https://github.com/alexcrichton/openssl-src-rs
[2] https://docs.rs/system-deps/latest/system_deps/#overriding-build-flags
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Certain parts of the README file still refer to concepts removed from
libgpiod v2. Update whatever needs updating.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Update the Tools section to reflect the changes to the tools for v2.
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In order to make the licensing situation of libgpiod clear and enable
easy reusing of the code, let's make all the files in the repository
compliant with the REUSE v3.0 specification.
In order to achieve that:
- put all used licenses into a separate LICENSES/ directory
- add SPDX license identifiers to all files that were missing them with
regular text files being licensed under CC-BY-SA-4.0, while files
containing code and configuration are licensed under GPL-2.0-or-later
- replace custom copyright texts with SPDX-FileCopyrightText
- update the gpio.h kernel uAPI header with the upstream version where
the SDPX license identifier was fixed to use 'GPL-2.0-only' variant
instead of the deprecated 'GPL-2.0'
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Kent Gibson <warthog618@gmail.com>
The project now depends on v5.5 kernel headers to build. Drop the
reference to v4.8 headers and instead refer readers to the contents
of configure.ac for the exact required version.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add information about the tests included in Python and C++ bindings.
Move the BINDINGS section above TESTING so that the user first knows
that bindings exist before learning they also provide their own
test-suites.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Doxygen and python documentation are briefly mentioned in the BINDINGS
section but there's no word about the core C API and automatically
generated man pages.
Add a separate section to the README file describing the process of
generating html doxygen output, python help strings and man pages for
gpio-tools.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
There's no need to use autogen.sh if building from release tarballs as
the configure script is already provided. Only git builds need
autoreconf.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
We now host libgpiod at kernel.org, so no need for the .md file.
This also fixes 'make dist' as README.md was not being packaged by
autotools.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
