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 host python always had --disable-unicodedata, regardless of the
corresponding configuration option BR2_PACKAGE_PYTHON_UNICODEDATA.
Since the host python is used to byte-compile python modules, this meant
that such modules could not contain unicode strings. For example, following
statement in a python module:
print u"\N{SOLIDUS}"
would cause the byte-compilation to fail with message:
SyntaxError: ("(unicode error) \\N escapes not supported (can't load
unicodedata module)",
Instead, conditionally disable unicodedata based on
BR2_PACKAGE_PYTHON_UNICODEDATA, also for the host python.
This fixes bug #6542 (https://bugs.busybox.net/show_bug.cgi?id=6542)
Reported-by: Gernot Vormayr <gvormayr@gmail.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.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>
Transmission would incorrectly determine the C++ compiler when ccache is
enabled, causing a build with uTP to fail at the configure step.
This patch adds a patch against transmission, fixing the problem.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If BR2_PACKAGE_QT_STATIC is set, qtuio will not build a .so file, but .a.
However, the custom INSTALL_TARGET_CMDS and INSTALL_STAGING_CMDS
unconditionally attempted to copy the .so file.
This commit checks the requested Qt library type and copies the right
library for each case, taking into account that the static .a file does not
need to be copied to the target directory.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The devicetree data for BeagleBone Black is the am335x–boneblack.dts file
(includes "am33xx.dtsi" and "am335x-bone-common.dtsi")
BeagleBone White uses the am335x-bone.dts file.
Signed-off-by: Marcelo Gutiérrez <kuyurix@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If Lua support is requested in VLC, its configure script tries to find the
luac byte compiler, which fails if host-lua is not yet built.
This can be easily reproduced by setting a minimal config with vlc and Lua
enabled, and running: 'make clean toolchain vlc'. Final output is:
checking for LUA... no
configure: WARNING: Package lua5.2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.2' found, trying lua 5.1 instead
checking for LUA... no
configure: WARNING: Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found, trying lua >= 5.1 instead
checking for LUA... yes
checking for luac... no
configure: error: Could not find the LUA byte compiler.
make: *** [<buildroot>/output/build/vlc-2.1.2/.stamp_configured] Error 1
Fix this problem by setting host-lua as a dependency to vlc.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It does not make much sense enabling opencv without its core module.
This configuration leads to build nothing (since all modules depend on
the core one), but install the configuration files (*.pc and *.cmake)
anyway.
This absurd situation may break the build-system of other packages
that would correctly find the *.pc (but does not check for the modules
they actually use), but would not build because of missing headers and
libraries.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
jimtcl tries to use 'ccache' (a non-buildroot host version) which may not
exist on the host system. If ccache is enabled in buildroot, the compiler
used by jimtcl is:
ccache <buildroot>/.../ccache <buildroot>/.../<tuple>-gcc
If ccache is not present on the host, this results in the build error:
ccache <buildroot>/.../ccache <buildroot>/.../<tuple>-gcc
-D_GNU_SOURCE -Wall -I. -fpic -pipe -Os -c -o jim-subcmd.o jim-subcmd.c
make[1]: ccache: Command not found
This patch passes 'CCACHE=none' to the 'configure' script, disabling the
internal handling of ccache, so that ccache can be transparently passed
through CC.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.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>
The three typical packages that use .config files in buildroot copy the
config file at different times in the build process:
busybox copies its .config from the post-extract hook.
linux copies its .config in the configure_cmds.
uclibc copies its .config from the post-patch hook.
Copying the .config file from the configure step is the only way to properly
support an OVERRIDE_SRCDIR that does not yet have the .config file, because
the extract and patch steps are skipped in that case.
In a previous patch, the situation was already fixed for busybox. This patch
applies the same fix to uclibc: copy the config file from the configure
step, as linux is doing.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The three typical packages that use .config files in buildroot copy the
config file at different times in the build process:
busybox copies its .config from the post-extract hook.
linux copies its .config in the configure_cmds.
uclibc copies its .config from the post-patch hook.
Copying the .config file from the configure step is the only way to properly
support an OVERRIDE_SRCDIR that does not yet have the .config file, because
the extract and patch steps are skipped in that case.
For example, when setting a BUSYBOX_OVERRIDE_SRCDIR to a cleanly extracted
busybox tarball:
$ make busybox-dirclean busybox
rm -Rf [..]/output/build/busybox-custom
>>> busybox custom Syncing from source dir
>>> /home/tdescham/repo/contrib/busybox-1.21.1
rsync -au --exclude .svn --exclude .git --exclude .hg --exclude .bzr
--exclude CVS /home/tdescham/repo/contrib/busybox-1.21.1/
[..]/output/build/busybox-custom
>>> busybox custom Configuring
/bin/sed -i -e "/\\<CONFIG_NOMMU\\>/d"
[..]/output/build/busybox-custom/.config
/bin/sed: can't read [..]/output/build/busybox-custom/.config:
No such file or directory
make: *** [[..]/output/build/busybox-custom/.stamp_configured] Error 2
This patch modifies busybox.mk to copy the config file from the configure
step instead, as linux is doing, and fixing the described scenario.
This fixes bug #5030: https://bugs.busybox.net/show_bug.cgi?id=5030
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.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>
