The default Python version for pylibfdt is already Python 3 but if
called without specifiying an interpreter, the setup.py script gets
called with Python 2.
It's of course still possible to call setup.py with python2 directly.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Message-Id: <20190907152530.25102-1-luca@z3ntu.xyz>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently setup.py depends on being invoked from the right directory
(specifically it needs to be run from the root of the project). That's a
bit confusing.
This updates setup.py to no longer depend on the invoking directory by
instead having it change directory to the location of the script itself,
then using internal paths relative to that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently setup.py expects the library version in a VERSION environment
variable, or it exctracts the version from the Makefile. The latter is
for the case where the script is run standalone, rather than from make.
But parsing the Makefile is ugly and fragile, and won't always get the
same version we put into the C code.
This changes to instead extracting the version from the trivial .h file we
already generate to put the version into C code. It's still slightly ugly,
but it's simpler and since we can control the precise format of that .h,
not as fragile.
This lets us remove the remains of the makefile parsing code from setup.py.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
At the moment we have some fiddly code to either pass in make's CPPFLAGS to
setup.py, or have setup.py extract them from the Makefile. But really the
only thing we need from here is the include paths. We already know what
include paths we need (libfdt/) so we can just set that directly in
setup.py.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently we build the Python extension module from all the libfdt source
files as well as the swig wrapper file. This is a bit silly, since we've
already compiled libfdt itself.
This changes the build to instead build the extension module from just the
swig wrapper, linking it against the libfdt.a we've already build.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
Our Makefile currently passes PYLIBFDT_objdir into setup.py in an attempt
to set the correct place to put the Python extension module output. But
that gets passed in the 'package_dir' map in distutils.
But that's basically not what package_dir controls. What actually makes us
find the module in the right place is the --inplace passed to setup.py
(causing the module to go into the current directory), and the following
'mv' in the Makefile to move it into the right final location.
We can simplify setup.py by dropping the useless objdir stuff, and get the
module put in the right place straight way by instead using the --build-lib
setup.py option.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
pylibfdt/setup.py currently adds include flags to the extension module
build to allow include files in the base dtc directory. But pylibfdt
doesn't rely on any headers there, only on headers in libfdt/ - it also
shouldn't rely on dtc headers at any future time.
So, remove that from the include list, allowing some simplifications to
setup.py.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Simon Glass <sjg@chromium.org>
The pylibfdt code is written for Python2, not Python3. So, it's safer to
explicitly request Python2 in our scripts and when checking pkg-config.
On Arch Linux at least, there isn't actually a plain "python" link, just
"python2" and "python3", so the current setup won't work at all.
According to https://www.python.org/dev/peps/pep-0394/ using "python2"
should work, and is preferred.
Updating pylibfdt to work with Python3 would be nice, but is a problem for
another day.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present we require that setup.py is executed from the Makefile, which
sets up various important things like the list of files to build and the
version number.
However many installation systems expect to be able to change to the
directory containing setup.py and run it. This allows them to support (for
example) building/installing for multiple Python versions, varying
installation paths, particular C flags, etc.
The problem in implementing this is that we don't want to duplicate the
information in the Makefile. A common solution (so I am told) is to parse
the Makefile to obtain the required information.
Update the setup.py script to read a few Makefiles when it does not see
the required information in its environment. This allows installation
using:
./pylibfdt/setup.py install
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We should follow PEP8 even for our setup() call.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Use the same version number in the module as with the rest of libfdt. This
can be examined with:
import pkg_resources
print pkg_resources.require('libfdt')[0].version
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present we manually move _libfdt.so into the correct place. Provide a
package directory so we can avoid needing to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
At present setup.py adjusts its command line when running, so that the
C flags and file list can be passed as arguments. Pass them in environment
variables instead, so we can avoid this messiness. It also allows us to
support the 'install' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Add Python bindings for a bare-bones set of libfdt functions. These allow
navigating the tree and reading node names and properties.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Luca Weiss