buildroot
Public
Source
committed c99a0deec78xxxxxxxxxx// -*- mode:doc; -*-// vim: set syntax=asciidoc:=== Infrastructure for Python packagesThis infrastructure applies to Python packages that use the standardPython setuptools mechanism as their build system, generallyrecognizable by the usage of a +setup.py+ script.[[python-package-tutorial]]==== +python-package+ tutorialFirst, let's see how to write a +.mk+ file for a Python package,with an example :------------------------01: ################################################################################02: #03: # python-foo04: #05: ################################################################################06:07: PYTHON_FOO_VERSION = 1.008: PYTHON_FOO_SOURCE = python-foo-$(PYTHON_FOO_VERSION).tar.xz09: PYTHON_FOO_SITE = http://www.foosoftware.org/download10: PYTHON_FOO_LICENSE = BSD-3c11: PYTHON_FOO_LICENSE_FILES = LICENSE12: PYTHON_FOO_ENV = SOME_VAR=113: PYTHON_FOO_DEPENDENCIES = libmad14: PYTHON_FOO_SETUP_TYPE = distutils15:16: $(eval $(python-package))------------------------On line 7, we declare the version of the package.On line 8 and 9, we declare the name of the tarball (xz-ed tarballrecommended) and the location of the tarball on the Web. Buildrootwill automatically download the tarball from this location.On line 10 and 11, we give licensing details about the package (itslicense on line 10, and the file containing the license text on line11).On line 12, we tell Buildroot to pass custom options to the Python+setup.py+ script when it is configuring the package.On line 13, we declare our dependencies, so that they are builtbefore the build process of our package starts.On line 14, we declare the specific Python build system being used. Inthis case the +distutils+ Python build system is used. The twosupported ones are +distutils+ and +setuptools+.Finally, on line 16, we invoke the +python-package+ macro thatgenerates all the Makefile rules that actually allow the package to bebuilt.[[python-package-reference]]==== +python-package+ referenceAs a policy, packages that merely provide Python modules should all benamed +python-<something>+ in Buildroot. Other packages that use thePython build system, but are not Python modules, can freely choosetheir name (existing examples in Buildroot are +scons+ and+supervisor+).In their +Config.in+ file, they should depend on +BR2_PACKAGE_PYTHON+so that when Buildroot will enable Python 3 usage for modules, we willbe able to enable Python modules progressively on Python 3.The main macro of the Python package infrastructure is+python-package+. It is similar to the +generic-package+ macro. It isalso possible to create Python host packages with the+host-python-package+ macro.Just like the generic infrastructure, the Python infrastructure worksby defining a number of variables before calling the +python-package+or +host-python-package+ macros.All the package metadata information variables that exist in thexref:generic-package-reference[generic package infrastructure] alsoexist in the Python infrastructure: +PYTHON_FOO_VERSION+,+PYTHON_FOO_SOURCE+, +PYTHON_FOO_PATCH+, +PYTHON_FOO_SITE+,+PYTHON_FOO_SUBDIR+, +PYTHON_FOO_DEPENDENCIES+, +PYTHON_FOO_LICENSE+,+PYTHON_FOO_LICENSE_FILES+, +PYTHON_FOO_INSTALL_STAGING+, etc.Note that: * It is not necessary to add +python+ or +host-python+ in the