Several files are not being included in distro tarballs so the
functionality of the python build is limited compared to the repo. Add
them to EXTRA_DIST.
Fixes: d588a6a592 ("bindings: python: standalone build tooling for tests")
Fixes: 72d2fa01a2 ("bindings: python: add script to generate sdist and wheels")
Fixes: 85089d0e40 ("bindings: python: add pyproject.toml, pep 518")
Fixes: 389a966d4e ("bindings: python: move long_description into README.md")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The modules are installed in the .egg directory, and therefore cannot be
imported after that. Additionally PIP tries to remove the global gpiod
module if it's not invoked with the --ignore-installed option.
Specify correct --root and fix the --prefix switch.
Link: https://github.com/pypa/pip/issues/3063
Suggested-by: Maxim Devaev <mdevaev@gmail.com>
Reported-by: Maxim Devaev <mdevaev@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Move extension definitions and tooling for building tests into
`build_tests.py` and update Makefile.am to call it with appropriate path
prefixes.
`build_tests.py` will perform a standalone build of the text extensions,
keeping any build noise in a temporary directory and copying the final
built modules automatically out to `tests/gpiosim` and `tests/procname`.
Add "python-tests-run" to Makefile.am so it's clear how to run the tests.
Add .so object files generated by build_test.py to Makefile.am's
clean-local.
Signed-off-by: Phil Howard <phil@gadgetoid.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The manifest is not being bundled with the distribution tarball. Add it
to EXTRA_DIST.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This reverts commit addf968c73.
We're moving towards being compatible with PEP 517 for building and
currently the following error happens when running setup.py build_py:
running build_py
error: Error: setup script specifies an absolute path:
<snip>/libgpiod/bindings/python/./gpiod/ext/chip.c
setup() arguments must *always* be /-separated paths relative to the
setup.py directory, *never* absolute paths.
As the Makefile build should only be used for development purposes, I
think we can safely drop support for out-of-tree build. Python bindings
have now been spun out into their own tarball and are available to
install from pip.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
GPIOD_VERSION_STRING environment variable is no longer used by setup.py.
It's been replaced by reading the version from the variable defined in
version.py.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The GPIOD_WITH_TESTS environment variable is not used by setup.py install
command. Drop it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As per automake docs:
The DESTDIR variable can be used to perform a staged installation. The
package should be configured as if it was going to be installed in its
final location (e.g., --prefix /usr), but when running make install, the
DESTDIR should be set to the absolute name of a directory into which the
installation will be diverted. From this directory it is easy to review
which files are being installed where, and finally copy them to their
final location by some means.
Prefix $(prefix) with $(DESTDIR) when calling setup.py.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Makefile.am delegates the build of the python extension to its
setup.py file, which references the extension .c files relative to the
source dir. This makes it impossible to build in a directory that is
different from the source directory (for example, for PC and ARM but
from the same source).
* Invoke setup.py from $(srcdir)
* Modify setup.py to pick up .c files relative from setup.py's own
directory.
Signed-off-by: Joerg Faschingbauer <jf@faschingbauer.co.at>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This commit is the result of a squash of all the commits created during
the development of libgpiod v2. This is done to preserve bisectability
of the git tree. It contains significant re-writes of the core C library
as well as C++ and python bindings. The tools have been adjusted to work
with the new API but have not undergone significant changes yet.
This commit contains the bulk of the work on libgpiod v2 but the
development continues with more changes planned.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
[Ben: fix format specifier for uint64_t]
Signed-off-by: Ben Hutchings <ben.hutchings@mind.be>
[Viresh: Fix ioctl number for gpiod_line_request_reconfigure_lines()]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[Kent: bug fixes, improvements, better pointer contracts, type strictness]
Signed-off-by: Kent Gibson <warthog618@gmail.com>
LGPL-2.1 is a license meant for shared libraries. Because I didn't know
any better I used it for all files in the repository, including programs
linking against libgpiod. The standard approach for many similar projects
is to use LGPL for library code and GPL for programs (and also Makefiles
and other files containing code or configuration).
Relicense all programs, tests, makefiles and autotools files under
GPL-2.0 or later.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Kent Gibson <warthog618@gmail.com>
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>
Example code for bindings is currently always built if bindings are
enabled. Make it conditional with a new configure switch.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We're already using it implicitly but GCC may change the default
standard to gnu99 at some point, so use gnu89 explicitly whenever
building C files.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Currently the only tests we have for python bindings are in a simple
script that makes a lot of assumptions about the environment and
doesn't even work anymore with recent kernels.
Remove it and replace it with a proper test-suite implemented using
libgpiod and the standard python unittest package.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The src directory containing lib and tools is not necessary and will
actually cause problems if we tried to add a new component to src/
which would depend on libraries from the bindings directory because it
(bindings) already depends on src/lib.
Simplify the directory structure. Move lib and tools to the root source
directory and update all relevant files. That way we can specify the
exact build order of components from the top source Makefile.am.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
AX_PYTHON_DEVEL macro from the autoconf-archive collection doesn't work
when we're trying to cross-compile python bindings in environments such
as buildroot or yocto. It can't properly detect the location of python
headers.
Let's use AM_PATH_PYTHON to detect the python3 interpreter and then
either take the PYTHON_CPPFLAGS and PYTHON_LIBS variables from the
environment (so that cross-compiling build systems can pass their
custom locations to autotools) or try to detect them ourselves using
the python3-config tool.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
Create a C extension module wrapping the functionality of libgpiod
in a set of Python classes.
Add code examples including simplified reimplementations of gpio-tools
in Python.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
