aboutsummaryrefslogtreecommitdiff
path: root/pylibfdt/setup.py
AgeCommit message (Collapse)AuthorFilesLines
2021-11-11pylibfdt: Move setup.py to the top levelRob Herring1-50/+0
Using 'pip' and several setup.py sub-commands currently don't work with pylibfdt. The primary reason is Python packaging has opinions on the directory structure of repositories and one of those appears to be the inability to reference source files outside of setup.py's subtree. This means a sdist cannot be created with all necessary source components (i.e. libfdt headers). Moving setup.py to the top-level solves these problems. With this change. the following commands now work: Creating packages for pypi.org: ./setup.py sdist bdist_wheel Using pip for installs: pip install . pip install git+http://github.com/robherring/dtc.git@pypi-v2 Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20211111011135.2386773-5-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-11pylibfdt: Split setup.py author name and emailRob Herring1-1/+2
The 'author' field in setup.py is supposed to be just the name. The email address goes in 'author_email' field. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20211111011135.2386773-4-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-11pylibfdt: Use setuptools_scm for the versionRob Herring1-14/+4
The DTC version in version_gen.h causes a warning with setuptools: setuptools/dist.py:501: UserWarning: The version specified ('1.6.1-g5454474d') \ is an invalid version, this may not work as expected with newer versions of \ setuptools, pip, and PyPI. Please see PEP 440 for more details. It also creates an unnecessary dependency on the rest of the build system(s). Switch to use setuptools_scm instead to get the version for pylibfdt. Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20211111011135.2386773-3-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-11-11pylibfdt: Use setuptools instead of distutilsRob Herring1-1/+1
The use of setuptools is favored over distutils. setuptools is needed to support building Python 'wheels' and for pip support. Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20211111011135.2386773-2-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-10-21pylibfdt: allow build out of treeMarc-André Lureau1-8/+19
With meson, we have to support out-of-tree build. Introduce a --top-builddir option, which will default to the current directory to lookup generated filed such as version_gen.h and output directories. Other source paths are derived from the location of the setup.py script in the source tree. --build-lib is changed to be relative to the current directory, instead of relative to setup.py. This has less surprising results! Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-2-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-09-09pylibfdt: use python3 shebangLuca Weiss1-1/+4
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>
2019-06-21pylibfdt: Replace dual GPLv2/BSD license boilerplate with SPDX tagsRob Herring1-0/+1
Replace pylibfdt GPLv2/BSD license boilerplate and add missing license with SPDX tags. Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20190620211944.9378-4-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-11-23PEP8 / Flake8 cleanups for setup.pyDavid Gibson1-6/+7
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-09-25pylibfdt: Don't have setup.py depend on where it's invoked fromDavid Gibson1-5/+8
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>
2018-09-25pylibfdt: Improved version extractionDavid Gibson1-71/+7
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>
2018-09-25pylibfdt: Simpler CFLAGS handlingDavid Gibson1-7/+4
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>
2018-09-25pylibfdt: Link extension module with libfdt rather than rebuildingDavid Gibson1-11/+6
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>
2018-09-25pylibfdt: Correctly set build output directoryDavid Gibson1-8/+3
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>
2018-09-25pylibfdt: We don't need include files from the base directoryDavid Gibson1-7/+3
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>
2017-09-27pylibfdt: Use Python2 explicitlyDavid Gibson1-1/+1
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>
2017-04-08pylibfdt: Allow setup.py to operate stand-aloneSimon Glass1-6/+92
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>
2017-04-07pylibfdt: Fix code style in setup.pySimon Glass1-8/+9
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>
2017-03-29pylibfdt: Use the correct libfdt version in the moduleSimon Glass1-1/+2
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>
2017-03-27pylibfdt: Use package_dir to set the package directorySimon Glass1-0/+3
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>
2017-03-27pylibfdt: Use environment to pass C flags and filesSimon Glass1-10/+6
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>
2017-03-21Add an initial Python library for libfdtSimon Glass1-0/+34
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>