Bump buidlroot version to 2018.02.6
This commit is contained in:
@@ -22,7 +22,7 @@ system is based on hand-written Makefiles or shell scripts.
|
||||
07: LIBFOO_VERSION = 1.0
|
||||
08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
|
||||
09: LIBFOO_SITE = http://www.foosoftware.org/download
|
||||
10: LIBFOO_LICENSE = GPLv3+
|
||||
10: LIBFOO_LICENSE = GPL-3.0+
|
||||
11: LIBFOO_LICENSE_FILES = COPYING
|
||||
12: LIBFOO_INSTALL_STAGING = YES
|
||||
13: LIBFOO_CONFIG_SCRIPTS = libfoo-config
|
||||
@@ -197,12 +197,25 @@ information is (assuming the package name is +libfoo+) :
|
||||
* +LIBFOO_VERSION+, mandatory, must contain the version of the
|
||||
package. Note that if +HOST_LIBFOO_VERSION+ doesn't exist, it is
|
||||
assumed to be the same as +LIBFOO_VERSION+. It can also be a
|
||||
revision number, branch or tag for packages that are fetched
|
||||
directly from their revision control system. +
|
||||
Examples: +
|
||||
+LIBFOO_VERSION = 0.1.2+ +
|
||||
+LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+ +
|
||||
+LIBFOO_VERSION = stable+
|
||||
revision number or a tag for packages that are fetched directly
|
||||
from their version control system. Examples:
|
||||
** a version for a release tarball: +LIBFOO_VERSION = 0.1.2+
|
||||
** a sha1 for a git tree: +LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057+
|
||||
** a tag for a git tree +LIBFOO_VERSION = v0.1.2+
|
||||
+
|
||||
.Note:
|
||||
Using a branch name as +FOO_VERSION+ is not supported, because it does
|
||||
not and can not work as people would expect it should:
|
||||
+
|
||||
1. due to local caching, Buildroot will not re-fetch the repository,
|
||||
so people who expect to be able to follow the remote repository
|
||||
would be quite surprised and disappointed;
|
||||
2. because two builds can never be perfectly simultaneous, and because
|
||||
the remote repository may get new commits on the branch anytime,
|
||||
two users, using the same Buildroot tree and building the same
|
||||
configuration, may get different source, thus rendering the build
|
||||
non reproducible, and people would be quite surprised and
|
||||
disappointed.
|
||||
|
||||
* +LIBFOO_SOURCE+ may contain the name of the tarball of the package,
|
||||
which Buildroot will use to download the tarball from
|
||||
@@ -263,7 +276,7 @@ information is (assuming the package name is +libfoo+) :
|
||||
the file using this URL. Otherwise, Buildroot will assume the file
|
||||
to be downloaded is located at +LIBFOO_SITE+. Buildroot will not do
|
||||
anything with those additional files, except download them: it will
|
||||
be up to the package recipe to use them from +$(BR2_DL_DIR)+.
|
||||
be up to the package recipe to use them from +$(DL_DIR)+.
|
||||
|
||||
* +LIBFOO_SITE_METHOD+ determines the method used to fetch or copy the
|
||||
package source code. In many cases, Buildroot guesses the method
|
||||
@@ -399,8 +412,8 @@ information is (assuming the package name is +libfoo+) :
|
||||
* +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
|
||||
is released.
|
||||
This name will appear in the manifest file produced by +make legal-info+.
|
||||
If the license appears in xref:legal-info-list-licenses[the following list],
|
||||
use the same string to make the manifest file uniform.
|
||||
If the license appears in https://spdx.org/licenses/[the SPDX License List],
|
||||
use the SPDX short identifier to make the manifest file uniform.
|
||||
Otherwise, describe the license in a precise and concise way, avoiding
|
||||
ambiguous names such as +BSD+ which actually name a family of licenses.
|
||||
This variable is optional. If it is not defined, +unknown+ will appear in
|
||||
@@ -408,12 +421,12 @@ information is (assuming the package name is +libfoo+) :
|
||||
The expected format for this variable must comply with the following rules:
|
||||
** If different parts of the package are released under different
|
||||
licenses, then +comma+ separate licenses (e.g. +`LIBFOO_LICENSE =
|
||||
GPLv2+, LGPLv2.1+`+). If there is clear distinction between which
|
||||
GPL-2.0+, LGPL-2.1+`+). If there is clear distinction between which
|
||||
component is licensed under what license, then annotate the license
|
||||
with that component, between parenthesis (e.g. +`LIBFOO_LICENSE =
|
||||
GPLv2+ (programs), LGPLv2.1+ (libraries)`+).
|
||||
GPL-2.0+ (programs), LGPL-2.1+ (libraries)`+).
|
||||
** If the package is dual licensed, then separate licenses with the
|
||||
+or+ keyword (e.g. +`LIBFOO_LICENSE = AFLv2.1 or GPLv2+`+).
|
||||
+or+ keyword (e.g. +`LIBFOO_LICENSE = AFL-2.1 or GPL-2.0+`+).
|
||||
|
||||
* +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
|
||||
tarball that contain the license(s) under which the package is released.
|
||||
@@ -453,6 +466,13 @@ information is (assuming the package name is +libfoo+) :
|
||||
FLAT binary format is only 4k bytes. If the application consumes more stack,
|
||||
append the required number here.
|
||||
|
||||
* +LIBFOO_BIN_ARCH_EXCLUDE+ is a space-separated list of paths (relative
|
||||
to the target directory) to ignore when checking that the package
|
||||
installs correctly cross-compiled binaries. You seldom need to set this
|
||||
variable, unless the package installs binary blobs outside the default
|
||||
locations, `/lib/firmware`, `/usr/lib/firmware`, `/lib/modules`,
|
||||
`/usr/lib/modules`, and `/usr/share`, which are automatically excluded.
|
||||
|
||||
The recommended way to define these variables is to use the following
|
||||
syntax:
|
||||
|
||||
@@ -540,6 +560,9 @@ In the action definitions, you can use the following variables:
|
||||
* +$(@D)+, which contains the directory in which the package source
|
||||
code has been uncompressed.
|
||||
|
||||
* +$(DL_DIR)+ contains the path to the directory where all the downloads made
|
||||
by Buildroot are stored.
|
||||
|
||||
* +$(TARGET_CC)+, +$(TARGET_LD)+, etc. to get the target
|
||||
cross-compilation utilities
|
||||
|
||||
|
||||
Reference in New Issue
Block a user