There is no debug profile on cargo. The available profiles are: dev
(enabled by default), release, test and bench.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since Gitlab 12.9, Gitlab allow to trigger child pipeline with generated configuration file.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/35632
This allow us to stop updating the .gitlab-ci.yml file when a
new defconfig is added to Buildroot.
Remove check-gitlab-ci.yml job since it is now uneeded.
Remove .gitlab-ci.yml make target.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[ann.morin.1998@free.fr: manual: no longer needed to update at all]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As Cargo is either installed by host-rust or host-rust-bin, the
Cargo-based packages should depend on host-rustc.
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
[Arnout: also select HOST_RUSTC in Config.in]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: David Pierret <david.pierret@smile.fr>
Tested-by: David Pierret <david.pierret@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Describe release engineering and development phases of the project.
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the linux kernel will apply some fixups on its .config file,
based on whether some packages are enabled or not. That list of
conditional fixups is getting bigger and bigger with each new package
that needs such fixups, culminating with the pending firewalld one [0].
Furthermore, these fixups are not accessible to packages in br2-external
trees.
Add a new per-package variable, that packages may set to the commands to
run to fixup the kernel .config file, which is added at the end of the
linux' own fixups.
This opens the possibility to write things like;
define FOO_LINUX_CONFIG_FIXUPS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
Of course, it also opens the way to run arbitrary commands in there, but
any alternative that would be declarative only, such as a list of
options to enable or disable (as an example):
FOO_LINUX_CONFIG_FIXUPS = +BAR -FOO +BUZ="value"
.. is not very nice either, and such lists fall flat when a value would
have a space.
For packages that we have in-tree, we can ensure they won't play foul
with their _LINUX_CONFIG_FIXUPS. For packages in br2-external trees,
there's nothing we can do; users already have the opportunity to hack
into the linux configure process by providing LINUX_PRE_CONFIGURE_HOOKS
or LINUX_POST_CONFIGURE_HOOKS anyway...
.. which brings the question of why we don't use that to implement the
per-package fixups. We don't, because _PRE or _POST_CONFIGURE_HOOKS are
run after we run 'make oldconfig' to sanitise the mangled .config.
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix a few punctuation mistakes. The removed link is redundant, see the
previous sentence.
Signed-off-by: Merlin Büge <merlin.buege@tuhh.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
With autoconf packages, we often specify ac_cv_func_... cached values to
avoid runtime checks during configure. With meson the equivalent is
setting properties in cross-compilation.conf which we cannot do in
Buildroot at the moment.
For example, libglib2 used to set ac_cv_func_printf_unix98 and
ac_cv_func_vsnprintf_c99 so that the system printf could be used, but
with the conversion to meson these checks fail and the gnulib fallback
is used.
Add infrastructure in the same way as FOO_MESON_EXTRA_BINARIES to allow
per-package modification to the cross-compilation properties.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Reviewed-by: Adam Duskett <aduskett@gmail.com>
[yann.morin.1998@free.fr: do a single substitution as in a1e3c7b693]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This provides generic functions for Qt5 qmake based packages. It will
make it possible to remove lots of redefinition of
QT5_xxx_{CONFIGURE|BUILD|INSTALL_STAGING}_CMDS. Additionally it
provides a generic target install method which will make most of the
package specific commands obsolete.
This is done by re-running the install step of the qmake generated
Makefile with the package build directory prepended (to the
staging/host path). Even though this does create lengthy pathes it
allows for easy separation of the staging files from the host destined
files by just omitting the resulting BUILD_DIR+HOST_DIR path from the
following rsync call to the real target folder. The cleanup of many
files we dont want in target is deferred to the target-finalize
step. In addition to what's being removed already, we also have to
cleanup some Qt5 specific files (prl) and the documentation directory.
This approach was chosen over copying all files recorded in the pkg-files-list
after some discussion which Thomas Petazzoni summed up:
"We don't yet use pkg-files-list really as part of the build
process anywhere, I feel a bit more comfortable at this point with what
Andreas is proposing."
Thanks to this infrastructure, it will be possible to get rid of the
many conditional install commands because qmake already takes care of
this when generating the Makefile install targets with the given or
autodetected configure options of each package.
However, custom install steps may have to remain in cases where a
particular Buildroot option has no corresponding setting in the
packages configuration options.
Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Unlike <PKG>_DEPENDENCIES, <PKG>_PATCH_DEPENDENCIES only guarantees
extract and patch of listed dependencies, not build. Make this subtlety
more explicit in the documentation.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[yann.morin.1998@free.fr: slight fix]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Package optional or choice config symbols are usually prefixed with the
package config symbol name. Rename BR2_PACKAGE_CURL to
BR2_PACKAGE_LIBCURL_CURL to conform.
Update references to the old name.
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The seperation of the fields in the hash file should be 2 spaces for
consitency
Update the manual accordingly.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[yann.morin.1998@free.fr:
- drop the notes part, reword the first hunk
- update the examples
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This list dates back to 2012. Since a long time now Buildroot saves the
patches applied as well as the actual source code for some external
toolchains. Update the manual accordingly.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch adds a new manual section that captures an overview
of the run-tests tool, how to manually run a test and where to
find the test case script.
A brief set of steps is included to go through how to add a new
test case and suggestions on how to test/debug.
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
[yann.morin.1998@free.fr:
- switch the creating and debugging sections
- minor reformatting
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update dependency documentation to detail the order-only relationship
associated with the DEPENDENCIES variable. See the thread at [1] for
details.
[1] http://lists.busybox.net/pipermail/buildroot/2019-October/262685.html
Signed-off-by: Dan Walkes <danwalkes@trellis-logic.com>
[yann.morin.1998@free.fr: indentation & slight rephrasing]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
since v234 upstream recommands using systemctl preset-all to enable units.
* add a buildroot specific preset file
* use that file to disable getty@tty1
* make systemd depend on host-systemd
* remove all link-creating code that systemd does for us.
Most packages will not be affected by this change, but a few packages
were installing units without manually enabling them. Those packages
will now be automatically enabled.
The fact that those packages were not enabled is almost certainly a bug,
but it is a change of behaviour that needs to be reported
host-systemd also builds udevadm for the host. That means we no longer
need to depend on host-eudev to provide udevadm (that would conflict).
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
[yann.morin.1998@free.fr:
- also remove the hwdb sources on fs generation
- fix check-package errors
- few typoes and reformatting in commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As suggested by Arnout Vandecappelle, this commit adjusts the
generic-package documentation to document the effect of per-package
directory support on HOST_DIR, STAGING_DIR and TARGET_DIR.
Suggested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: change version reference to Buildroot 2020.02]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Update the documentation for the output/host/ directory to mention
that it contains the sysroot for the target toolchain, as well as the
host tools required for running buildroot.
Update the staging/ documentation to reflect that it is a link to the
target toolchain sysroot in the host/ directory.
Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Laurent reported that a short tutorial was missing in the manual to
explain how to reuse a Buildroot toolchain as external toolchain.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Laurent Guillier <laurent.guillier@smile.fr>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>
[Thomas: completely rewrite the thing]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since commit 6eacea5a (support/kconfig: bump to kconfig from Linux
4.17-rc2), xconfig uses Qt5, so update prerequisite.txt to match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, the formatting we impose on the _LICENSE variable requires
that we also use the rarely used := assignment operator, which makes
the _LICENSE variable the only variable that users have to write with
this operator.
This really departs from the simplicity and consistency of using the
append-assignment, which we use for every other variable.
This is because the append-assignment operator surreptiously
introduces a space between the original value and the appended one. But
we can use this knowledge, to match any instance of a space followed by
a comma, and turn it into a single comma.
This allows users to now have a consistent use of the '=' and '+='
operators we use everywhere else in .mk files.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, we only require a gcc 4.4 version, which now is pretty old
(released in April 2009). This requirement is not even tested nowadays,
with our oldest autobuilder having a 4.7 version only.
And even then, 4.7 is still old enough that it prevents us from
upgrading some packages. For example cmake 3.10+ requires C++11
constructs that were only added in gcc 4.8 (when C++11 support was
finally completed in gcc).
So, update our requirements for gcc to at least 4.8.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since <package>-rebuild implies <package>-reinstall and
<package>-reconfigure implies <package>-rebuild, it is confusing
to mention the make and make <package> commands when describing
the restart of the configuration, compilation and installation of
the package.
Therefore remove the ", followed by +make+ or +make <package>+"
portions in the "8.3. Understanding how to rebuild packages" section,
and add a new paragraph clarifying how to include the rebuilt package
in the filesystem image, if that is necessary.
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Back in commit 025b863e6f, the option
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS was introduced, to
separate the option that host packages needing Rust should depend on
(BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS) from the option that target
packages needing Rust should depend on
(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS).
Since the example in the manual is showing a target package, we must
use BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Sam Voss <sam.voss@gmail.com>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
meson does not allow passing path to helper programs (e.g. pkgconfig)
using variables in the environment. Instead, it insists that those paths
be defined in the cross-compilation.conf file, in the [binaries]
section [0]
As such, allow packages to declare such a list of arbitrary entries to
add in the [binaries] section.
[0] https://github.com/mesonbuild/meson/issues/3327 for the LLVM_CONFIG
example, which we'll address in a follow-up patch.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: McCabe, Robert J <robert.mccabe@rockwellcollins.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add an OpenRC service that starts and stops sysv-init scripts. We order
that script 'after local' so that it is started after all other native
openrc services.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
[yann.morin.1998@free.fr:
- don't propagate the micro optimisation for running .sh scripts
- use spaces, not TABs
- stop services in reverse order
- reword commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If follow through the customize-outside-br.txt with how to add external
toolchain in br-ext tree then one thing is missing - inclusion of
*.mk file with external toolchain package description.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Python packages should no longer depend on BR2_PACKAGE_PYTHON in their
config file, unless they are only compatible with Python 2.
Signed-off-by: Raphaël Mélotte <raphael.melotte@essensium.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, the packages are sorted smallest first, and biggest last
(with unknown and others second-to-last and last, resp.).
Add an option to invert the ordering (but keeping unknown and others at
their current positions).
This has the nice side effect that we can now control the colours
assigned to the biggest package(s), as the colours are cycled from the
first to the last. Currently, the biggest packages gets a redish colour,
which is appropriate, but the second gets a greenish one, which is not
as appropriate (but changing that can come later).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When dealing with embedded devices, storage is more often than not some
kind of flash device, on which the memory is usually counted as powers
of 1024 instead of powers of 1000. As such, people may prefer reports
using IEC prefixes [0] instead of the SI prefixes.
Add an option to that effect.
We use argparse's ability to use custom actions [1] [2], to provide a
set of options that act on a boolean, but has a single help entry and
internally ensures consistency of the settings. We could have been using
the more conventional store_true/store_false actions instead, but that
would have meant either two help entries, one for each set of options,
and/or some logic after parse_args() to check the validity of the
settings.
[0] https://en.wikipedia.org/wiki/Binary_prefix
[1] https://docs.python.org/2/library/argparse.html#action
[2] https://docs.python.org/2/library/argparse.html#argparse.Action
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, we group packages that contribute less then 1%, into the
"Other" category.
However, in some cases, there can be a lot of very comparatively small
packages, and they may not exceed this limit, and so only the "Others"
category would be displayed, which is not nice.
Conversely, if there are a lot of packages, most of which only so
slightly exceeding this limit, then we get all of them in the graph,
which is not nice either.
Add a way for the developers to pass a different cut-off limit. As for
the dependency graph which has BR2_GRAPH_DEPS_OPTS, add the environment
variable BR2_GRAPH_SIZE_OPTS to carry those extra option (in preparation
for more to come, later).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout:
- remove empty base class definition from Config;
- use parser.error instead of ValueError for invalid argument.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Acked-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Briefly states what the output of this target is about.
Signed-off-by: Marcel Patzlaff <m.patzlaff@pilz.de>
[Thomas: improve wording]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add documentation about how a br2-external tree can provide an external
toolchain or a libjpeg or openssl alternative implementation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This rule was added back in 9429e7b698 (core: introduce an intermediate
rule before the configurators) when the kconfig-side br2-external file
was generated separately from the Makefile-side one.
Now that they are generated together very early in the Makefile, we no
longer need this intermediate rule. Drop it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
[Peter: also drop outdated reference in the manual]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the two (all of them!) br2-external related files are generated
in the same location, it makes sense they are named after the same
pattern.
When initial support for (then single) br2-external trees was added back
in a4239f7fd1 (core: introduce the BR2_EXTERNAL variable), it was not
clear-cut why that file was not named with a br2 prefix.
So rename it now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Apparently, patchwork only recognizes the 'Fixes' tag if it is followed
by a colon. So make sure the manual documents it as such.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Meson does not allow to pass CFLAGS/LDFLAGS/CXXFLAGS via the environment
or via command-line arguments or options (instead, those flags from the
environment are passed to the host compiler, which is seldom what we
need). The only way to pas those flags is via the cross-compilation.conf
file.
Add LIBFOO_CFLAGS, LIBFOO_LDFLAGS and LIBFOO_CXXFLAGS variables to allow
packages to provide their own flags, possibly overriding the generic
ones entirely, as we allow for other infras. Those per-package flags will
then be used to generate the per-package cross-compilation.conf.
This means that the meson infra is the first and only infra for which
FOO_CFLAGS, FOO_LDFLAGS, and FOO_CXXFLAGS are meaningful, while for the
other infras, they are just variables private to the package itself.
Instead of naming those variables after the meson infra (e.g.
FOO_MESON_CFLAGS), we name them with a generic name, as maybe, just
maybe, we could also change the other infras to also recognise those
variables.
Just like for the HOST_MESON_SED_CFLAGS etc., we need to add auxiliary
variables to do convert the shell-formatted argument list into the
JSON-formatted list that meson expects. We can't use a pure-make
construct because the CFLAGS can contain quoting that needs to be
expanded by the shell. Similarly, we need a condition on the strip'ed
variable to avoid passing empty arguments.
To mimic this feature for packages that are built from the SDK, we also
install a templatised version of cross-compilation.conf, with three new
placeholders for custom flags. If a user wants to build a package that
needs custom flags, they can use that template to generate a per-package
cross-compilation.conf.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* package/pkg-generic.mk
Add <pkg>_INSTALL_INIT_OPENRC so packages can define their own steps
to install openrc service scripts.
* docs/manual/adding-packages-generic.txt
update documentation about new hook.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In particular, the manual was incorrect when the user had selected an
out-of-tree build.
Signed-off-by: Charlie Turner <cturner@igalia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With this you can add:
$(eval $(host-golang-package))
to a package .mk file to build for host.
Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Acked-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The hidden Config.in option BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS name is
not very clear as to whether it says whether Go is available for the
target architecture or the host architecture.
Until now, this was fine since there was support for host Go
packages. But as we are about to introduce support for building host
Go packages, we need to clarify the meaning of
BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS. Since it says whether the target
architecture has support for Go or not, we rename it to
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS.
And since BR2_PACKAGE_HOST_GO_CGO_LINKING_SUPPORTS is tightly related,
we rename it to BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
[Thomas: entirely rewrite commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a 'VARS=...' setting to the example. To make it clear that several
variables can be specified, use two variables in the first example.
Only 2 variables are printed, so the ... is removed.
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@bootlin.com>
No functional change is brought by this modification.
This patch:
* removes redundant <pkg>_SRCDIR and <pkg>_BUILDDIR declarations
(already defined in pkg-generic.mk)
* documents the usage of <pkg>_SUBDIR in the python-specific section of
the manual.
Signed-off-by: Lionel Orry <lionel.orry@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
No functional change is brought by this modification.
This patch:
* removes a redundant <pkg>_SRCDIR declaration (already defined in
pkg-generic.mk)
* documents the usage of <pkg>_SUBDIR in the meson-specific section of
the manual.
Signed-off-by: Lionel Orry <lionel.orry@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In the Buildroot manual, it is specified that the Waf-based
infrastructure supports the <pkg>_SUBDIR variable, which was not true.
This patch:
* makes use of this variable by changing to the given sub-directory
before executing waf commands,
* documents the usage of <pkg>_SUBDIR in the waf-specific section of
the manual.
Signed-off-by: Lionel Orry <lionel.orry@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a step to target-finalize that checks each rootfs overlay, following
the criteria established for custom skeletons and using the same script
uesd by skeleton-custom.mk.
Add a paragraph to the documentation clarifying that rootfs overlays
don't need to contain /bin, /lib or /sbin and must not contain them when
BR2_ROOTFS_MERGED_USR is enabled.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
skeleton-custom does not install the required /bin, /lib and /sbin
directories (or symlinks), which may result in an imcomplete tree, The
user could add the required directories/symlinks to the skeleton but
they may be invalid, depending on the state of BR2_ROOTFS_MERGED_USR.
Steps to reproduce:
- Enable BR2_ROOTFS_MERGED_USR and BR2_INIT_SYSTEMD
- Set BR2_ROOTFS_SKELETON_CUSTOM_PATH to "system/skeleton"
- Run "make skeleton"
- target/{bin.lib,sbin} will not exist
Add calls to SYSTEM_USR_SYMLINKS_OR_DIRS to INSTALL_TARGET_CMDS and
INSTALL_STAGING_CMDS, so the required directories or symlinks are
created.
Add a paragraph to the documentation clarifying that custom skeletons
don't need to contain /bin, /lib or /sbin and must not contain them when
BR2_ROOTFS_MERGED_USR is enabled.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We now require python 2.7+, so update prerequisite.txt to match.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit updates package-make-target.txt with a few additional
useful per-package targets that have been added in recent times.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, our commit titles are not very well standardized, and it
would be great to standardize them a little bit more. A number of
people use "<pkg>: " as prefix, others use "package/<pkg>: ". Some
people start the rest of the commit title (after the prefix) with an
upper-case letter, some with a lower-case letter.
In an attempt to standardize this, this commit updates the manual with
some examples of good commit titles.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Carlos Santos <casantos@datacom.com.br>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The script is utils/get-developers but the manual refers to get-developer in
several places.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This addon allows to generate a Buildroot package from a Luarocks
package definition.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some packages may want to build only specific targets, instead of the
default.
So, allow them to provide FOO_NINJA_OPTS (not really options, but we
just mimicked the naming we already have for autotools packages).
Update the manual accordingly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
external.desc must be present when using a br2-external tree. The
documentation notes this later in the text, but the file is missing
from the initial overview of files.
Fixes bug #11481.
Signed-off-by: Philipp Wagner <mail@philipp-wagner.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This variable is needed for upgrading packages with scancpan.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Explain how this can be used with git send-email, and how git can be
configured to use it automatically.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As discussed in [1], our guideline for the ordering of 'depends on'
lines is not written down. Fix that.
[1] http://lists.busybox.net/pipermail/buildroot/2018-October/232413.html
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some users of kconfig need some packages to be built before their
kconfig infra be used.
For example, the linux kernel, starting with 4.16, needs flex and bison
to generate the parser code. Furthermore, starting with 4.18, it will
also need the cross-compiler before parsing the kconfig stuff, because
that calls the compiler to check its features.
Currently, this is broken, even the flex/bison ones, even though they
are listed, because there is no way to define dependencie that are
guaranteed before the (visual) configurators. For example:
$ make distclean
$ make menuconfig
--> enable the linux kernel, choose a defconfig, save, exit
$ make linux-menuconfig
[...]
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
/bin/sh: bison: command not found
LEX scripts/kconfig/zconf.lex.c
scripts/Makefile.lib:196: recipe for target 'scripts/kconfig/zconf.tab.c' failed
make[3]: *** [scripts/kconfig/zconf.tab.c] Error 127
make[3]: *** Waiting for unfinished jobs....
/bin/sh: flex: command not found
scripts/Makefile.lib:188: recipe for target 'scripts/kconfig/zconf.lex.c' failed
make[3]: *** [scripts/kconfig/zconf.lex.c] Error 127
Makefile:528: recipe for target 'rpc_defconfig' failed
make[2]: *** [rpc_defconfig] Error 2
linux/linux.mk:511: recipe for target '/home/ymorin/dev/buildroot/buildroot/output/build/linux-4.17.11/.config' failed
make[1]: *** [/home/ymorin/dev/buildroot/buildroot/output/build/linux-4.17.11/.config] Error 2
Makefile:79: recipe for target '_all' failed
make: *** [_all] Error 2
So, we introduce a new type of dependencies for kconfig-based packages,
that are guaranteed to be built and installed before the (visual)
configurators are called.
Since those dependencies are phony targets and therefore always out of
date, a normal dependency would cause the .config target to be rebuilt
on each invocation of make. So we use an order-only pre-requisite, like
is done for the patch dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, the wording in the manual instructs the user to generate a
tarball from "the contents of the +output/host+ directory".
This is pretty confusing, because taken literally, this would amount to
running a command like:
tar cf my-sdk.tar -C output/host/ .
This creates a tarbomb [0], which is very bad practice, because when
extracted, it creates multiple files in the current directory.
What one really wants to do, is create a tarball of the host/ directory,
with something like:
tar cf my-sdk.tar -C output host/
However, this is not much better, because the top-most directory would
have a very common name, host/, which is pretty easy to get conflict
with when it gets extracted.
So, we fix that mess by giving the top-most directory a recognisable
name, based on the target tuple, which we also use as the name of the
archive (suffixed with the usual +.tar.gz+.) We offer the user the
possibility to override that default by specifying the +BR2_SDK_PREFIX+
variable on the command line.
Since this is an output file, we place it in the images/ directory.
As some users expressed a very strong feeling that they do not want to
generate a tarball at all, and that doing so would badly hurt their
workflows [1], we actually prepare the SDK as was previously done, but
under the new, intermediate rule 'prepare-sdk'. The existing 'sdk' rule
obviously depend on that before generating the tarball.
We choose to make the existing rule to generate the tarball, and
introduce a new rule to just prepare the SDK, rather than keep the
existing rule as-is and introduce a new one to generate the tarball,
because it makes sense to have the simplest rule do the correct thing,
leaving advanced, power users use the longest command. If someone
already had a wrapper that called 'sdk' and expected just the host
directory to be prepared, then this is not broken; it just takes a bit
longer (gzip is pretty fast).
Update the manual accordingly.
[0] https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb
[1] http://lists.busybox.net/pipermail/buildroot/2018-June/thread.html#223377
and some messages in the ensuing thread...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Stefan Becker <chemobejk@gmail.com>
Cc: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Reviewed-by: Stefan Becker <chemobejk@gmail.com>
Signed-off-by: "Yann E. MORIN" <<a href="mailto:yann.morin.1998@free.fr" target="_blank">yann.morin.1998@free.fr</a>><br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The oldest gcc that is known to work with current Buildroot is that of
RHEL 6, version 4.4.
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@bootlin.com>
scancpan is now in utils not in supports/scripts
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The manual is GPL-2, and points to the COPYING file in the repository.
When we do a rendering of the manual for a specific version, that URL
is currently always poitning to the latest version of the COPYING file.
If we ever have to change the content of that file (e.g. to add a new
exception, more clarifications, a license change, or whatever), then
an old manual would point to that newer version, which would then be
incorrect.
Include the sha1 of the commit in the URL, so that the manual always
point to the tree at the time the manual was rendered, not the time
it is consulted. Contrary to the informative text above, use the full
sha1, not the shortened one.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
As per section 12.2 "Complying with the Buildroot license", Buildroot
is released under GPL version 2 or (at your option) any later version.
But SPDX license string for Buildroot license in section 21.5
"Submitting patches" refers to only GPL version 2. Fix this
inconsistency by using correct SPDX identifier.
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Explicitly state that one tab counts for 8 columns in package
description, leaving 62 characters to the text itself.
Update the text and the example in the two places where the Config.in
format is described.
Also mention a newline is expected between the help text itself and the
upstream URL.
This blob can help developers to understand the expected formatting.
Also, it can be referenced by reviewers.
http://patchwork.ozlabs.org/patch/611289/http://patchwork.ozlabs.org/patch/606866/http://patchwork.ozlabs.org/patch/459960/
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We want to use SPDX short identifier for license string as much as
possible. So refer to SPDX license list and use SPDX short identifier
for license strings in documentation.
Also remove License abbreviations that we have.
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
[Thomas: take into account suggestions from Arnout.]
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the output of printvars copntains the name of the variable,
its expanded value and its un-expanded value.
However, most of the time, we need the actual, expanded value, so it can
be re-used from a (non-Buildroot) infrastructure script, like a
post-build script, or a build-farm driver (e.g. a Jenkins job...)
Add two options that a user may set to change the output of printvars:
- QUOTED_VARS, if set, will quote the value
- RAW_VARS, if set, will print the unexpanded value
The new output by default only prints the expanded value now.
So that it can be used as such:
$ make -s printvars VARS=BUSYBOX_VERSION
BUSYBOX_VERSION=1.26.2
$ make -s printvars VARS=BUSYBOX_RDEPENDENCIES QUOTED_VARS=YES
BUSYBOX_RDEPENDENCIES='ncurses util-linux'
$ make -s printvars VARS=BUSYBOX_FINAL_PATCH_DEPENDENCIES RAW_VARS=YES
BUSYBOX_FINAL_PATCH_DEPENDENCIES=$(sort $(BUSYBOX_PATCH_DEPENDENCIES))
And it is even possible to directly evaluate it in a shell script:
eval $(make -s printvars VARS=BUSYBOX_VERSION QUOTED_VARS=YES)
Backward compatibility of the output is not maintained. It is believed
that scripts that depended on the previous output were very fragile to
begin with, because they had to filter the non-formatted output
(splitting on spaces or braces was not really possible, because values
could contain either).
Document printvars and its options in the manual; list it in the output
of 'make help'.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Many packages are provided under MPL v1.1 and v2.0. Document it under
License abbreviations section.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Many packages are provided under ISC license. Document it under License
abbreviations section.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
LuaRocks has a policy that the rockspec and rock filenames are lower
case. However, the upstream name may contain uppercase characters.
We have several packages like that in Buildroot. To simplify the
package .mk files, apply the lowercase from within the infra.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we now require Lua package names to start with "lua", it is likely
that the Buildroot name is different from the upstream LuaRocks name.
Add a feature to the luarocks-package infra that makes it easier to
handle this situation: the package can explicitly specify the upstream
name in PKG_NAME_UPSTREAM, and that name will be used in PKG_ROCKSPEC,
PKG_SOURCE and PKG_SUBDIR.
Add an explanation of this feature to the manual. To make the example
relevant, it is changed to lua-foo, where the upstream name is plain
foo. To avoid confusion with the dependency on a native library, that
dependency is renamed to bar.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The license file in a luarocks package is always inside the subdir, so the
example should reflect this.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We currently have two places where we recommend where BR2_DL_DIR
should be set: "Environment variables" and "Location of downloaded
packages". The former recommends setting BR2_DL_DIR in the .config,
the latter kind of endorses using ~/.bashrc.
We prefer suggesting the ~/.bashrc way since it avoids downloading the
same file multiple times, and anyway it's wise to have all the details
in a unique place. So remove the .config suggestion from "Environment
variables" and let it just point to "Location of downloaded packages".
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The manual mentions LIBFOO_GIT_SUBMODULES but does not tell what value
it should have. The implementation only checks whether the variable is
non-empty, but we should suggest a specific value to avoid people
wondering what they have to set, and to try setting weird values.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Ricardo Herrero <ricardo.herrero@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
