Update documentation about adding meson-based packages with instructions for
using pkg-meson infrastructure.
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For various reasons, we've always suggested users to avoid using a
branch as version string for their packages, because it does not work
as a they would expect:
- it is not reproducible, because the branch may change between two
builds that are done at different times;
- it does not even follow the branch, as Buildroot anyway generates
a local tarball, which it will reuse on subsequent builds.
Furthermore, since we fetch and not pull, any existing local branch
is not updated.
Yet, until recently, using a branch name would just work (with the
above limitations): the git tree was cloned, the branch checked out,
and the tarball created.
But with the advent of the git caching, using a branch name does not
work anymore. Indeed, we now do a git-fetch, and that does not create
a local master branch. So we can't check out master, because it does
not exist locally. And for other branches, as noticed above, the local
branch does not get udpated to the remote one.
Furthermore, the local branches are only created by chance, again as a
side-effect of trying to fetch the "special refs".
So, we can't say that we reliably support the use of a branch name.
Update the manual to state that using a branch does not work. Remove
the 'stable' example, as it looked like the name of a stable branch;
instead, replace it with a version string that ressemble a tag.
Fix the layout of the manual by making the version examples an actual
bulleted list.
Note: the above is only entirely true for git. For Mercurial, CVS and
subversion, the status may be mixed, but nonetheless, using branches is
still a bad idea, if at least because it is not reproducible, and
because Buildroot does not even follow the branch. So, we do not
differentiate between the various SCMs, and just flatly state that using
a branch name is not supported.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Update the documentation accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[yann.morin.1998@free.fr: slight rephrasing in error message, update manual]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
And add two references to it: in "Submitting patches" and in "Adding new
packages to Buildroot" sections.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The graph-depends was not very consistent in colors vs. colours: some
parts were using colours, some parts were using colors.
Let's settle on the US spelling, colors.
This change the user-visble option --colours to --colors, but it is
unlikely that a lot of users customize the colors through
BR2_GRAPH_DEPS_OPTS, so this user interface change is considered
reasonable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This allows using <PKG>_SRCDIR_OVERRIDE_RSYNC_EXCLUSIONS in local.mk to
skip copying parts of source trees unneeded for building. For example,
when developing WebKitGTK+, it's handy to skip copying all the tests and
other build directories, which are huge:
WEBKITGTK_OVERRIDE_SRCDIR = /home/aperez/WebKit
WEBKITGTK_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS = \
--exclude JSTests --exclude ManualTests \
--exclude PerformanceTests --exclude WebDriverTests \
--exclude WebKitBuild --exclude WebKitLibraries \
--exclude WebKit.xcworkspace --exclude Websites \
--exclude Examples
This saves a good chunk of time when rsync is used for the first time to
copy the source tree over before building.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Arnout: move documentation to the end of the section]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
Fixes:
http://autobuild.buildroot.net/results/1f9cd7c48e8c8f41326632a9c0de83915d72c45b/
[Peter: use $(or instead of $(if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
toolchain-common.in is a Config.in file with an uncommon name.
It is just included by toolchain/Config.in, and toolchain/Config.in is
not that long, so instead of renaming the file, merge it to
toolchain/Config.in.
Move the raw contents from the file to the exact location it is
currently included in order to not change the order in the menu.
Update the references in the manual as well.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds the documentation for the golang infrastructure.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Extract dependencies are dependencies that must be ready before the
extract step of a package, i.e for tools that are needed to extract
packages themselves. Current examples of such tools are host-tar,
host-lzip and host-xz.
They are currently handled through DEPENDENCIES_HOST_PREREQ. However,
this mechanism has a number of drawbacks:
- First and foremost, because host-tar/host-lzip/host-xz are not
listed in the dependencies of packages, the package infrastructure
does not know it should rsync them in the context of per-package
SDK.
- Second, there is no dependency handling *between* them. I.e, we
have no mechanism that says host-tar should be built before
host-lzip, while it is in fact the case: if you need to build
host-lzip, you need to extract a tarball, so you may need host-tar
if your system tarball is not capable enough.
For those reasons, it makes sense to add explicit support for "extract
dependencies" in the package infrastructure, through the
<pkg>_EXTRACT_DEPENDENCIES variable. It is unlikely this variable will
ever be used by a package .mk file, but it will be used internally by
the package infrastructure.
[Peter: fix typo in manual]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Ninja understands the `-j` option which defines how many jobs are
run in parallel.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When using a merged /usr, the kernel module path is really
/usr/lib/modules, as /lib is a symlink to usr/lib .
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages (mostly, out-of-tree) may want to install binary blobs for
another architecture, outside the locations we currently exclude, like
in /opt or whatever...
Add support in check-bin-arch to accept any arbitrary location, that
individual package can each request to excude from the check, when they
are installed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
utils/check-package complains as follows:
package/rustc/rustc.mk:10: possible typo: RUST_TARGET_NAME -> *RUSTC*
package/rustc/rustc.mk:18: possible typo: RUST_HOST_NAME -> *RUSTC*
As RUST_{HOST,TARGET}_NAME are related to the Rust compiler, it
sounds sensible to rename them to RUSTC_{HOST,TARGET}_NAME.
So update all rust related packages to use the new variables.
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add instructions for adding a package which uses Cargo as build system.
[Peter: fix indentation]
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add instructions for adding a package which uses the Meson build system.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 1e5a8916b2.
The idea was that the version string can be derived because we know the
package name.
However, this patch does not account for the fact that $(pkgname) always
points to the latest pacakge scanned, which in all other situation we're
using it, is the current package, because it is used inside one ot he
xxx-inner macros that are $(eval)ualed. So $(pkgname) is evaluated
"early" and gets the expected value.
However, the github value is not in one of those macros, so it gets
evaluated "late", when doing the actual download. So, by that time,
$(pkgname) will expand to the last package scanned, which is actuall the
manual (without a br2-external tree).
That would require that the _SITE variable be assigned with the :=
assignment operator. This is weird, because that would make it the only
variable to require that, but only when using the github helper, which
is even less obvious and would cause a lot of trouble...
The obvious fixup would seem to be to use $(PKG) instead, because that
already contains the upper-case package name that vcan be used as a
prefix to variables.
However, that does not work either, because we have a check that forbids
a trsailing slash in _SITE, check that is done in pacakge/pkg-generic,
inside the xxx-inner macro, during the $(eval) call.
And at that time, PKG is not yet defined, because it is only defined for
an actual recipe.
So we can't seem to have a workable solution. So, just revert the patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reiterate once more that <packagename>_PATCH variable can point
to an arbitrary URL, not just to a path relative to <packagename>_SITE.
While we're at it, also explain that the patch should be added to the
.hash file.
Signed-off-by: Alexander Mukhin <alexander.i.mukhin@gmail.com>
[Arnout: add sentence about .hash file.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently it is always required to add package version as an argument to
the github helper. Since the version is always defined as PKG_VERSION,
drop this argument and generate it automatically inside the helper
routine.
The github helper function is extended to support both 2 and 3 argument
variants (ie. either use the provided package version argument or
automatically substitute with PKG_VERSION if not available), which can
make the transition of the package files easier as well allows using the
3-argument variant outside of package definitions.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reported-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
... and move the br2-external migration to it.
Reported-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When we have multiple versions for a package, and the licensing terms
depend on the version actually selected (e.g. like Qt5), storing the
hashes for those license files in the .hash file is broken: the infra
will ensure that all hashes for a file do match, which would not be the
case here.
We fix that by first looking for a hash file in the version sub-dir
first, and if that does not exist, then we use the main hash file.
Drop the useless intermediate variable 'ret'.
Update the documentation accordingly.
Reported-by: Joshua Henderson <joshua.henderson@microchip.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Joshua Henderson <joshua.henderson@microchip.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make inclusion ordering of all linux-tool-*.mk sub-makefiles explicit
instead of relying on alphabetical sort order. This is done by
renaming the Linux tools sub-makefiles to the format linux-tool-*.mk.in.
This causes the top-level Makefile to ignore the Linux tools
sub-makefiles.
Until now, the main Makefile included all linux-tool-*.mk files, as
well as linux-tools.mk, and it relied on alphabetical sorting to
include them in the proper order (linux-tool-*.mk before
linux-tools.mk).
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: improve comment in the code as suggested by Yann.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We had several remarks on the mailing list of users that were surprised
that patches were not applied for packages whose SITE_METHOD is local.
So document this.
Note that for OVERRIDE_SRCDIR itself it is already documented:
When Buildroot finds that for a given package, an
<pkg>_OVERRIDE_SRCDIR has been defined, it will no longer attempt to
download, extract and patch the package. Instead, it will directly use
the source code available in in the specified directory.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The way gettext is handled in Buildroot has significantly changed,
with changes visible to packages. This commit updates the relevant
section of the manual to document how packages should now interact
with the gettext support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
And at the same time don't encourage use of BR2_DL_DIR
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Peter: use sha256 in example]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit updates the manual about hashes, fixing a number of
issues:
- Adding the .hash file should no longer be optional: it *must* be
added. Therefore the wording "You can add ..." is changed to "When
possible, you must add ...".
- We are now checking hashes for Git downloaded packages, so fix this
as well, and indicate more clearly which download methods have hash
checking.
- We no longer want to have auto-generated patches be downloaded
through <pkg>_PATCH because such patches are not stable over time,
and their hash can change. For example, downloading patches from
github.com should no longer be done.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There were still some references to the old location of the scripts in
the manual. Replace them by utils/.
While we're at it, remove the redundant ./ at the beginning of some of
the example commands.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After some discussion, we found out that "tools" has the four first
letters identical to the "toolchain" subfolder, which makes it a bit
unpractical with tab-completion. So, this commit renames "tools" to
"utils", which is more tab-completion-friendly.
This has been discussed with Arnout and Yann.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add brmake, a small script that redirects the build output log to a
file, keeping just Buildroot's own messages, with the date+time added
at the start of the line.
We need to unbuffer the output of make so that, when the script is
interrupted (SIGINT, ^C), there is no lingering output not yet digested
by the logger loop.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move it to the top-level tools/ directory, so that it is easier to
find for users.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move it to the top-level tools/ directory, so that it is easier to
find for users.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The CodeSourcery x86 and sh, the ADI Blackfin, and the Xilinx Mircoblaze
external toolchain profiles have all been removed. Update the manual.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Buildroot can build non-uClibc toolchains internally for quite some time now.
Update the manual text.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The advantages of using a pre-existing coding style instead of creating
our own are:
- documenting on the manual takes a single sentence;
- there are automatic tools to help during development/review.
So document that PEP8 recommendation should be followed.
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
