XBMC needs Java on the host in order to build, because it uses a
code-generator which is built in two phases: In the first phase SWIG is used
to parse C++ header files that define the API. SWIG outputs an XML file
that contains a complete description of the structure of the API. In the
second phase, the XML file is ingested by a Groovy (Java) program that then
creates C++ code that forms the bridge to the scripting language (Python).
The second phase is why we need java on the host.
You can learn more at the XBMC's wiki:
http://wiki.xbmc.org/index.php?title=Codegeneration#How_it_works
In order to check that, this patch introduce this mechanism in
dependencies.sh, and it also defines the variable in Config.in
[Peter: fix error message]
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Host version is needed to build xbmc
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Host version is needed to build xbmc
[Peter: use _PRE_CONFIGURE_HOOKS like target version]
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The https://code.google.com/p/pyasn/ project is not really the real
upstream for PyASN, and at least not the upstream for the PyASN
implementation recommended by the PySNMP developers.
Instead, the real upstream is
https://pypi.python.org/packages/source/p/pyasn1/, which has had much
more regular releases than the other PyASN implementation.
Therefore, we switch to using this implementation, as recommended by
the PySNMP developers on http://pysnmp.sourceforge.net/download.html.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The python and python3 builds mark libpython as read-only which
prevents it from being stripped out correctly for the target.
Signed-off-by: Przemyslaw Wrzos <przemyslaw.wrzos@calyptech.com>
Acked-by: Thomas De Schampheleire <thomas.de_schampheleire@alcatel-lucent.com>
Tested-by: Thomas De Schampheleire <thomas.de_schampheleire@alcatel-lucent.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Thomas: bump to 2.1.2 instead of 0.8, remove comment that no longer
made sense about setuptools being forked.]
Signed-off-by: Rohan Fletcher <rohfledev@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As we are going to bump setuptools to a much newer version, the host
python needs to be built with support for unicodedata.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Until now, Python external modules were only visible when Python 2.x
was selected. With this commit, we now source all the Config.in files
of Python external modules, as soon as one of the two Python
interpreters is enabled.
Since all Python external modules have a "depends on
BR2_PACKAGE_PYTHON" in their Config.in, this commit in practice does
not allow to enable any Python external module. However, thanks to
this, we can progressively and safely enable more and more Python
external modules to build with Python 3, by simply changing their
dependency to "depends on BR2_PACKAGE_PYTHON || BR2_PACKAGE_PYTHON3".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit improves the Python package infrastructure to allow Python
packages to be built with Python 3. The changes are fairly simple:
* Use either PYTHON_PATH or PYTHON3_PATH as the PYTHONPATH depending
on which Python is used.
* Depend on host-python or host-python3 and python or python3
depending on which Python is used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Python package infrastructure will need the Python 3 package to
provide a PYTHON3_PATH environment variable in order to build
third-party Python modules.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit bumps the Python3 package to use Python 3.4.0rc1.
About the patches:
* The patches below 100 are significantly changed, because like for
Python 2.x, a good number of improvements have been made in the
upstream Python for cross-compilation. Therefore, almost all of
these patches have been modified.
* All the patches above 100 are simply updated for Python 3.4.0, with
a small refactoring for the handling of test modules.
The details of the python3.mk changes are:
* --without-ensurepip to tell Python to not use PIP at build time.
* Many environment variables are no longer passed, they were specific
to our cross-compilation patches
* The fixup of the LIBDIR in the Python Makefile is no longer needed
since Python has switched to _sysconfigdata.py for distutils
configuration instead of parsing the Makefile.
* A new post patch hooks touches the two files generated by pgen to
make sure they are newer than the pgen sources, which ensures pgen
is not built/executed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some parts of python3.mk were hardcoding the 3.3 version as the major
version, which does not work for Python 3.4 and other future
versions. Instead, use the existing PYTHON3_VERSION_MAJOR.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The target python3 depends on host-python3, but most of the scripts
call "python", so we need to ensure that $(HOST_DIR)/usr/bin/python
exists. This patch achieves this by creating a python -> python3
symbolic link in $(HOST_DIR), just like we are already doing for the
target Python 3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In Buildroot, we do not support installing both Python 2.x and Python
3.x on the target.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thanks to the previous commit that makes distutilscross unecessary for
setuptools packages, the host-distutilscross package can now be
removed. There is no need for any Config.in.legacy handling, since
there is no target variant, or visible Config.in option for
host-distutilscross.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thanks to the bump of Python 2.x, distutilscross is no longer needed
to achieve cross-compilation for setuptools packages. The host Python
2.x interpreter can be tricked into using the target compiler thanks
to pointing it to a different sysconfigdata module, which is achieved
using PYTHON_PATH.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The expanded SED variable already contains -e, so the extra -e was being
interpreted as the sed command and causing sed to fail.
Signed-off-by: Ivan Sergeev <vsergeev@kumunetworks.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The main Buildroot Makefile was removing *.py or *.pyc if Python 2 was
enabled, but for Python 3, this action was taken care of by a post
install target hook of python3.mk, which means it wouldn't work with
external modules (the .py/.pyc removal would be done before external
Python modules are installed).
We fix this by making the global *.py/*.pyc removal in the main
Makefile work for both Python 2 and Python 3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thanks to the Python 2.x bump, it is no longer needed to pass
PYTHONCPREFIX, and CROSS_COMPILING when building third-party Python
modules.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though jumping from 2.7.3 to 2.7.6 looks like a minor version
bump, it is in fact a fairly significant one, because a good number of
changes to help cross-compilation have been merged into Python
upstream. Therefore, most of our patches are affected by this change.
In detail, this commit:
* Renames all the patches to follow the naming convention of patches
in Buildroot: the patch file names should not have any version
number.
* The patches numbered above 100, that add configuration options to
disable certain modules of the Python standard library, are only
renamed and slightly adapted, they didn't change that much.
* The patches numbered below 100 are almost entirely rewritten: many
of the cross-compilation problems that used to exist in Python
2.7.3 no longer exist, and the number of remaining problems is
smaller, and can be fixed with smaller patches.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the upcoming bump of Python 2.x, it will become important that
the PYTHONPATH is passed whenever we build third-party packages, be
they using the distutils build mechanism, or the setuptools build
mechanism. This is because passing PYTHONPATH is what will allow
Python to find a special Python module that contains all the
compiler/library/headers definitions that are relevant when
cross-compiling.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the Python package exposes its PYTHON_PATH variable, we can
use it in the package infrastructure. This prepares both the upcoming
bump of Python 2.x, and the introduction of Python 3 support in the
Python package infrastructure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As a preparation to make the Python infrastructure support both Python
and Python 3, as well as the bump of Python 2 and 3, we need the
Python package to expose the Python module path in a variable called
PYTHON_PATH. It will be used by the following commits.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch consolidates the URLs for various Freescale-supplied
packages to use FREESCALE_IMX_SITE.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Reviewed-by: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be sure that host-autoconf dependency is already built move the
call to autogen.sh from SDL_POST_PATCH_HOOKS to SDL_PRE_CONFIGURE_HOOKS.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After the latest patches top-level parallel Makefile is working but
there is still an issue when a package has an unspecified optional
dependency so change the comment to explain that.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add '+' prefix to the $($(PKG)_BUILD_CMDS) and $($(PKG)_INSTALL*_CMDS)
commands to enable jobserver for the sub-make.
Without the '+' prefix GNU make does not detect the sub-make so it
disable the jobserver for the sub-make.
>From GNU make documentation:
Using the MAKE variable has the same effect as using a ‘+’ character
at the beginning of the recipe line. This special feature is only
enabled if the MAKE variable appears directly in the recipe: it does
not apply if the MAKE variable is referenced through expansion of
another variable. In the latter case you must use the ‘+’ token to get
these special effects.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be able to use top-level parallel make we must not depend in a rule
on the order of evaluation of the prerequisites, so instead of relyng on
the left to right ordering of evaluation of the prerequisites add an
explicit rule to describe the dependencies.
Add explicit rules to describe the following dependency chain:
$(TARGETS) -> target-finalize -> rootfs-* -> target-post-image
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be able to use top-level parallel make we must not depend in a rule
on the order of evaluation of the prerequisites, so instead of relying
on the left to right ordering of evaluation of the prerequisites add
an explicit rule to describe the dependencies.
We cannot use the pattern rules because they must have the same
dependency for every package, but we need to change the dependencies
depending on $(2)_OVERRIDE_SRCDIR variable value, so we must use a
more flexible way like $(2)_TARGET_% variables.
So add explicit dependencies for the following stamp files:
$(2)_TARGET_EXTRACT
$(2)_TARGET_PATCH
$(2)_TARGET_CONFIGURE
$(2)_TARGET_BUILD
$(2)_TARGET_INSTALL_STAGING
$(2)_TARGET_INSTALL_TARGET
$(2)_TARGET_INSTALL_IMAGES
$(2)_TARGET_INSTALL_HOST
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
inner-generic-package right after the configuration phase, example:
make clean <package-name>
Also remove TARGETS_ALL because the only purpose was to add toolchain
dependency so it's superseded by this commit.
To prevent circular dependency add the new variable
<pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain
dependency for toolchain packages.
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Move "dependencies" "dirs" "prepare" dependencies from "toolchain" to
every package.
This way we can build correctly every package right after the clean
stage.
As example with this commit we can build successfully the glibc right
after the clean stage:
make clean glibc
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we are changing the default dbus user, make sure this user is
consistently created.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Change the download source to a Github repository which is more recent.
This patch also bump libatomic_ops version and remove a patch that is
now upstream.
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
glibc 2.19 has been released recently
(https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This
commit allows to build a toolchain with this new version. In order to
allow this, we add a version selection that did not exist for
glibc. We default to 2.18, which was the only supported version until
now, and add an option for 2.19.
For microblaze, which uses a specific glibc version, the version
selection choice is not displayed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 262a4c0bf7.
Compiler error has been fixed, and building this package doesn't cause an
ICE anymore.
Signed-off-by: Anton Kolesov <anton.kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
