rpi/domo
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Bump Buildroot Version to buildroot 2019_02_6

Browse Source
This commit is contained in:
NADAL Jean-Baptiste
2019-10-25 11:46:00 +02:00
parent e07322a5a8
commit c1075f68da
549 changed files with 6692 additions and 4165 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
bsp/buildroot/docs/manual/adding-packages-python.txt
View File

@@ -67,9 +67,13 @@ Python build system, but are not Python modules, can freely choose
their 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 will
be able to enable Python modules progressively on Python 3.
Packages that are only compatible with one version of Python (as in:
Python 2 or Python 3) should depend on that version explicitely in
their +Config.in+ file (+BR2_PACKAGE_PYTHON+ for Python 2,
+BR2_PACKAGE_PYTHON3+ for Python 3). Packages that are compatible
with both versions should not explicitely depend on them in their
+Config.in+ file, since that condition is already expressed for the
whole "External python modules" menu.
The main macro of the Python package infrastructure is
+python-package+. It is similar to the +generic-package+ macro. It is

4
bsp/buildroot/docs/manual/common-usage.txt
View File

@@ -310,8 +310,8 @@ installed (+python-matplotlib+ on most distributions), and also the
+argparse+ module if you're using a Python version older than 2.7
(+python-argparse+ on most distributions).
Just like for the duration graph, a +BR2_GRAPH_OUT+ environment is
supported to adjust the output file format. See xref:graph-depends[]
Just like for the duration graph, a +BR2_GRAPH_OUT+ environment variable
is supported to adjust the output file format. See xref:graph-depends[]
for details about this environment variable.
.Note

4
bsp/buildroot/docs/manual/contribute.txt
View File

@@ -73,7 +73,7 @@ basically two things that can be done:
In the commit message of a patch fixing an autobuild failure, add a
reference to the build result directory, as follows:
---------------------
Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
Fixes: http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
---------------------
=== Reviewing and testing patches
@@ -402,7 +402,7 @@ the problem is complex, it is OK to add more paragraphs. All paragraphs
should be wrapped at 72 characters.
A paragraph that explains the root cause of the problem. Again, more
than on paragraph is OK.
than one paragraph is OK.
Finally, one or more paragraphs that explain how the problem is solved.
Don't hesitate to explain complex solutions in detail.

137
bsp/buildroot/docs/manual/manual.html
View File

File diff suppressed because one or more lines are too long

BIN
bsp/buildroot/docs/manual/manual.pdf
View File

Binary file not shown.

163
bsp/buildroot/docs/manual/manual.text
View File

@@ -161,13 +161,13 @@ List of Examples
---------------------------------------------------------------------
Buildroot 2019.02.2 manual generated on 2019-04-29 08:38:35 UTC from
git revision 3b4b3e7cd4
Buildroot 2019.02.6 manual generated on 2019-10-03 15:16:21 UTC from
git revision 4564d8f397
The Buildroot manual is written by the Buildroot developers. It is
licensed under the GNU General Public License, version 2. Refer to
the COPYING [http://git.buildroot.org/buildroot/tree/COPYING?id=
3b4b3e7cd4618e56f5c6a8ea098ffd573a2e868e] file in the Buildroot
4564d8f3977a6ed448edf9567f4eb6a6b8c127c8] file in the Buildroot
sources for the full text of this license.
Copyright © 2004-2019 The Buildroot developers
@@ -362,9 +362,8 @@ All of these "make" commands will need to build a configuration
utility (including the interface), so you may need to install
"development" packages for relevant libraries used by the
configuration utilities. Refer to Chapter 2, System requirements for
more details, specifically the optional requirements Section 2.2,
“Optional packages” to get the dependencies of your favorite
interface.
more details, specifically the optional requirements to get the
dependencies of your favorite interface.
For each menu entry in the configuration tool, you can find
associated help that describes the purpose of the entry. Refer to
@@ -1469,10 +1468,10 @@ installed (python-matplotlib on most distributions), and also the
argparse module if you’re using a Python version older than 2.7
(python-argparse on most distributions).
Just like for the duration graph, a BR2_GRAPH_OUT environment is
supported to adjust the output file format. See Section 8.8,
“Graphing the dependencies between packages” for details about this
environment variable.
Just like for the duration graph, a BR2_GRAPH_OUT environment
variable is supported to adjust the output file format. See
Section 8.8, “Graphing the dependencies between packages” for details
about this environment variable.
Note. The collected filesystem size data is only meaningful after a
complete clean rebuild. Be sure to run make clean all before using
@@ -1738,10 +1737,8 @@ Additionally, there are some other useful make targets:
| graph-depends |Generate a dependency graph of the |
| |package, in the context of the |
| |current Buildroot configuration. See|
| |this section Section 8.8, “Graphing |
| |the dependencies between packages” |
| |for more details about dependency |
| |graphs. |
| |this section for more details about |
| |dependency graphs. |
|-----------------------+------------------------------------|
| graph-rdepends |Generate a graph of this package |
| |reverse dependencies (i.e the |
@@ -1793,10 +1790,21 @@ clean.
Therefore, Buildroot provides a specific mechanism for this use case:
the <pkg>_OVERRIDE_SRCDIR mechanism. Buildroot reads an override
file, which allows the user to tell Buildroot the location of the
source for certain packages. By default this override file is named
local.mk and located in the top directory of the Buildroot source
tree, but a different location can be specified through the
BR2_PACKAGE_OVERRIDE_FILE configuration option.
source for certain packages.
The default location of the override file is $(CONFIG_DIR)/local.mk,
as defined by the BR2_PACKAGE_OVERRIDE_FILE configuration option. $
(CONFIG_DIR) is the location of the Buildroot .config file, so
local.mk by default lives side-by-side with the .config file, which
means:
* In the top-level Buildroot source directory for in-tree builds
(i.e., when O= is not used)
* In the out-of-tree directory for out-of-tree builds (i.e., when O
= is used)
If a different location than these defaults is required, it can be
specified through the BR2_PACKAGE_OVERRIDE_FILE configuration option.
In this override file, Buildroot expects to find lines of the form:
@@ -1853,6 +1861,15 @@ WEBKITGTK_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = \
--exclude WebDriverTests --exclude WebKitBuild --exclude WebKitLibraries \
--exclude WebKit.xcworkspace --exclude Websites --exclude Examples
By default, Buildroot skips syncing of VCS artifacts (e.g., the .git
and .svn directories). Some packages prefer to have these VCS
directories available during build, for example for automatically
determining a precise commit reference for version information. To
undo this built-in filtering at a cost of a slower speed, add these
directories back:
LINUX_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = --include .git
Chapter 9. Project-specific customization
Typical actions you may need to perform for a given project are:
@@ -2520,8 +2537,7 @@ from the post-build script.
Instead, Buildroot provides support for so-called permission tables.
To use this feature, set config option BR2_ROOTFS_DEVICE_TABLE to a
space-separated list of permission tables, regular text files
following the makedev syntax Chapter 23, Makedev syntax documentation
.
following the makedev syntax.
If you are using a static device table (i.e. not using devtmpfs,
mdev, or (e)udev) then you can add device nodes using the same
@@ -2543,8 +2559,7 @@ Sometimes it is needed to add specific users in the target system. To
cover this requirement, Buildroot provides support for so-called
users tables. To use this feature, set config option
BR2_ROOTFS_USERS_TABLES to a space-separated list of users tables,
regular text files following the makeusers syntax Chapter 24,
Makeusers syntax documentation.
regular text files following the makeusers syntax.
As shown in Section 9.1, “Recommended directory structure”, the
recommended location for such files is board/<company>/<boardname>/.
@@ -3653,8 +3668,7 @@ also enabled, but not necessarily built before your package. To do
so, the dependency also needs to be expressed in the .mk file of the
package.
Further formatting details: see the coding style Section 15.1,
“Config.in file”.
Further formatting details: see the coding style.
17.2.4. Dependencies on target and toolchain options
@@ -3838,36 +3852,27 @@ different way, using different infrastructures:
infrastructure must be used for all packages that do not use the
autotools as their build system. In the future, other specialized
infrastructures might be written for other build systems. We
cover them through in a tutorial Section 17.5.1, “generic-package
tutorial” and a reference Section 17.5.2, “generic-package
reference”.
cover them through in a tutorial and a reference.
* Makefiles for autotools-based software (autoconf, automake,
etc.): We provide a dedicated infrastructure for such packages,
since autotools is a very common build system. This
infrastructure must be used for new packages that rely on the
autotools as their build system. We cover them through a tutorial
Section 17.6.1, “autotools-package tutorial” and reference
Section 17.6.2, “autotools-package reference”.
and reference.
* Makefiles for cmake-based software: We provide a dedicated
infrastructure for such packages, as CMake is a more and more
commonly used build system and has a standardized behaviour. This
infrastructure must be used for new packages that rely on CMake.
We cover them through a tutorial Section 17.7.1, “cmake-package
tutorial” and reference Section 17.7.2, “cmake-package reference”
.
We cover them through a tutorial and reference.
* Makefiles for Python modules: We have a dedicated infrastructure
for Python modules that use either the distutils or the
setuptools mechanism. We cover them through a tutorial
Section 17.8.1, “python-package tutorial” and a reference
Section 17.8.2, “python-package reference”.
setuptools mechanism. We cover them through a tutorial and a
reference.
* Makefiles for Lua modules: We have a dedicated infrastructure for
Lua modules available through the LuaRocks web site. We cover
them through a tutorial Section 17.9.1, “luarocks-package
tutorial” and a reference Section 17.9.2, “luarocks-package
reference”.
them through a tutorial and a reference.
Further formatting details: see the writing rules Section 15.2, “The
.mk file”.
Further formatting details: see the writing rules.
17.4. The .hash file
@@ -4209,9 +4214,9 @@ information is (assuming the package name is libfoo) :
are included in Buildroot itself use a different mechanism: all
files of the form *.patch present in the package directory inside
Buildroot will be applied to the package after extraction (see
patching a package Chapter 18, Patching a package). Finally,
patches listed in the LIBFOO_PATCH variable are applied before
the patches stored in the Buildroot package directory.
patching a package). Finally, patches listed in the LIBFOO_PATCH
variable are applied before the patches stored in the Buildroot
package directory.
* LIBFOO_SITE provides the location of the package, which can be a
URL or a local filesystem path. HTTP, FTP and SCP are supported
URL types for retrieving package tarballs. In these cases don’t
@@ -4870,9 +4875,13 @@ be named python-<something> in Buildroot. Other packages that use the
Python build system, but are not Python modules, can freely choose
their 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 will
be able to enable Python modules progressively on Python 3.
Packages that are only compatible with one version of Python (as in:
Python 2 or Python 3) should depend on that version explicitely in
their Config.in file (BR2_PACKAGE_PYTHON for Python 2,
BR2_PACKAGE_PYTHON3 for Python 3). Packages that are compatible with
both versions should not explicitely depend on them in their
Config.in file, since that condition is already expressed for the
whole "External python modules" menu.
The main macro of the Python package infrastructure is
python-package. It is similar to the generic-package macro. It is
@@ -4884,12 +4893,11 @@ by defining a number of variables before calling the python-package
or host-python-package macros.
All the package metadata information variables that exist in the
generic package infrastructure Section 17.5.2, “generic-package
reference” also exist 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.
generic package infrastructure also exist 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:
@@ -5807,9 +5815,8 @@ The Makefile starts with the definition of the standard variables for
package declaration (lines 7 to 11).
As seen in line 35, it is based on the generic-package infrastructure
Section 17.5.1, “generic-package tutorial”. So, it defines the
variables required by this particular infrastructure, where Cargo is
invoked:
. So, it defines the variables required by this particular
infrastructure, where Cargo is invoked:
* FOO_BUILD_CMDS: Cargo is invoked to perform the build. The
options required to configure the cross-compilation of the
@@ -5892,10 +5899,10 @@ Just like the generic infrastructure, the Go infrastructure works by
defining a number of variables before calling the golang-package.
All the package metadata information variables that exist in the
generic package infrastructure Section 17.5.2, “generic-package
reference” also exist in the Go infrastructure: FOO_VERSION,
FOO_SOURCE, FOO_PATCH, FOO_SITE, FOO_SUBDIR, FOO_DEPENDENCIES,
FOO_LICENSE, FOO_LICENSE_FILES, FOO_INSTALL_STAGING, etc.
generic package infrastructure also exist in the Go infrastructure:
FOO_VERSION, FOO_SOURCE, FOO_PATCH, FOO_SITE, FOO_SUBDIR,
FOO_DEPENDENCIES, FOO_LICENSE, FOO_LICENSE_FILES,
FOO_INSTALL_STAGING, etc.
Note that it is not necessary to add host-go in the FOO_DEPENDENCIES
variable of a package, since this basic dependency is automatically
@@ -5984,8 +5991,7 @@ On line 13, we invoke the kernel-module helper infrastructure, that
generates all the appropriate Makefile rules and variables to build
that kernel module.
Finally, on line 14, we invoke the generic-package infrastructure
Section 17.5.1, “generic-package tutorial”.
Finally, on line 14, we invoke the generic-package infrastructure.
The dependency on linux is automatically added, so it is not needed
to specify it in FOO_DEPENDENCIES.
@@ -6097,10 +6103,9 @@ there is, as for packages, an infrastructure for rendering documents
using the AsciiDoc syntax.
Also as for packages, the AsciiDoc infrastructure is available from a
br2-external tree Section 9.2, “Keeping customizations outside of
Buildroot”. This allows documentation for a br2-external tree to
match the Buildroot documentation, as it will be rendered to the same
formats and use the same layout and theme.
br2-external tree. This allows documentation for a br2-external tree
to match the Buildroot documentation, as it will be rendered to the
same formats and use the same layout and theme.
17.19.1. asciidoc-document tutorial
@@ -6271,10 +6276,9 @@ only when the foo tool is selected.
The rest of the Makefile, lines 11-25 defines what should be done at
the different steps of the Linux tool build process like for a
generic package Section 17.5.1, “generic-package tutorial”. They will
actually be used only when the foo tool is selected. The only
supported commands are _BUILD_CMDS, _INSTALL_STAGING_CMDS and
_INSTALL_TARGET_CMDS.
generic package. They will actually be used only when the foo tool is
selected. The only supported commands are _BUILD_CMDS,
_INSTALL_STAGING_CMDS and _INSTALL_TARGET_CMDS.
Note. One must not call $(eval $(generic-package)) or any other
package infrastructure! Linux tools are not packages by themselves,
@@ -6335,8 +6339,7 @@ modify the Linux kernel tree; this is specific to the linux extension
and can use the variables defined by the foo package, like: $
(FOO_DIR) or $(FOO_VERSION)… as well as all the Linux variables,
like: $(LINUX_VERSION) or $(LINUX_VERSION_PROBED), $(KERNEL_ARCH)…
See the definition of those kernel variables Section 17.18.2,
“kernel-module reference”.
See the definition of those kernel variables.
17.21. Hooks available in the various build steps
@@ -6926,7 +6929,7 @@ basically two things that can be done:
patch fixing an autobuild failure, add a reference to the
build result directory, as follows:
Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
Fixes: http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
21.3. Reviewing and testing patches
@@ -7124,8 +7127,8 @@ options that no longer exist or are no longer needed.
If you are interested in getting notified of build failures and of
further changes in the packages you added or modified, please add
yourself to the DEVELOPERS file. This should be done in the same
patch creating or modifying the package. See the DEVELOPERS file
Chapter 22, DEVELOPERS file and get-developers for more information.
patch creating or modifying the package. See the DEVELOPERS file for
more information.
Buildroot provides a handy tool to check for common coding style
mistakes on files you created or modified, called check-package (see
@@ -7233,7 +7236,7 @@ the problem is complex, it is OK to add more paragraphs. All paragraphs
should be wrapped at 72 characters.
A paragraph that explains the root cause of the problem. Again, more
than on paragraph is OK.
than one paragraph is OK.
Finally, one or more paragraphs that explain how the problem is solved.
Don't hesitate to explain complex solutions in detail.
@@ -7283,14 +7286,12 @@ as superseded.
21.6. Reporting issues/bugs or getting help
Before reporting any issue, please check in the mailing list archive
Chapter 5, Community resources whether someone has already reported
and/or fixed a similar problem.
whether someone has already reported and/or fixed a similar problem.
However you choose to report bugs or get help, either by opening a
bug in the bug tracker Chapter 5, Community resources or by sending a
mail to the mailing list Chapter 5, Community resources, there are a
number of details to provide in order to help people reproduce and
find a solution to the issue.
bug in the bug tracker or by sending a mail to the mailing list,
there are a number of details to provide in order to help people
reproduce and find a solution to the issue.
Try to think as if you were trying to help someone else; in that
case, what would you need?

30
bsp/buildroot/docs/manual/using-buildroot-development.txt
View File

@@ -28,10 +28,22 @@ clean+.
Therefore, Buildroot provides a specific mechanism for this use case:
the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
file, which allows the user to tell Buildroot the location of the
source for certain packages. By default this _override_ file is named
+local.mk+ and located in the top directory of the Buildroot source
tree, but a different location can be specified through the
+BR2_PACKAGE_OVERRIDE_FILE+ configuration option.
source for certain packages.
The default location of the override file is +$(CONFIG_DIR)/local.mk+,
as defined by the +BR2_PACKAGE_OVERRIDE_FILE+ configuration option.
+$(CONFIG_DIR)+ is the location of the Buildroot +.config+ file, so
+local.mk+ by default lives side-by-side with the +.config+ file,
which means:
* In the top-level Buildroot source directory for in-tree builds
(i.e., when +O=+ is not used)
* In the out-of-tree directory for out-of-tree builds (i.e., when
+O=+ is used)
If a different location than these defaults is required, it can be
specified through the +BR2_PACKAGE_OVERRIDE_FILE+ configuration
option.
In this _override_ file, Buildroot expects to find lines of the form:
@@ -97,3 +109,13 @@ WEBKITGTK_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = \
--exclude WebDriverTests --exclude WebKitBuild --exclude WebKitLibraries \
--exclude WebKit.xcworkspace --exclude Websites --exclude Examples
------------------
By default, Buildroot skips syncing of VCS artifacts (e.g., the *.git* and
*.svn* directories). Some packages prefer to have these VCS directories
available during build, for example for automatically determining a precise
commit reference for version information. To undo this built-in filtering at a
cost of a slower speed, add these directories back:
------------------
LINUX_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = --include .git
------------------