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>
Since we are using the standard .i extension for the swig file, we can use
setup.py to build the wrapper. Drop the existing build code since it is
not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current mechanism uses a shell construct, but it seems better to use
a Makefile approach.
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>
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>
The .i extension allows Python distutils to automatically handle the swig
file. Rename it.
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>
This is in a separate patch since I not sure if GNU make features
are permitted in the Makefile.
Signed-off-by: Simon Glass <sjg@chromium.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>
Adjust the setup script to support installation, and call it from the
Makefile if enabled. It will be disabled if we were unable to build the
module (e.g. due to swig being missing), or the NO_PYTHON environment
variable is set.
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>
David Gibson