The "toolchain-eclipse-register" target needs the toolchain so add
toolchain as a dependency.
This also fix the support to top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, graph-depends (and PKG-graph-depends) do not store the
intermediate 'dot' program.
Some users would like to get the dot program to be able to further
customise the generated graphs (eg. modify the layout, colorise some
of the packages...)
So, store the intermediate dot program alongside the generated graph.
Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This variable contains extra environment variables that we can not export
since they are clashing with some build systems (eg. BUILD_DIR with
u-boot).
So, we may need these variables for uses other than the user's hooks
for instrumentation. For example, we'll use them later on to export
BUILD_DIR to the download helper scripts.
Fix comment, too.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The usual way to enable a package using the package infrastructure is to
use a config option so instead to add the toolchain package to the
TARGETS variable in the Makefile add a config option like all the other
toolchain packages.
[Thomas: remove comment that no longer made sense in the main
Makefile, and add a comment above the new hidden Config.in option to
explain what it is useful for.]
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Extend BR_PATH because a few host-packages install programs in this
location.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since the HOST_PATH and TARGET_PATH variables almost contain the same
things, let's factorize this in a single BR_PATH.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the complete dependency chain of a package is used to
generate the dependency graph. When this dependency chain is long,
the generated graph becomes almost unreadable.
However, it is often sufficient to get the first few levels of
dependency of a package.
Add a new variable BR2_GRAPH_DEPTH, that the user can set to limit
the depth of the dependency list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Variables should be prefixed with BR_ when they are not user-facing.
As a side effect, the new variable is prettier than the previous one. :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After adding support top-level parallel make the rootfs-* dependencies
were not anymore considered for the "source" and "legal-info" targets
because the rootfs-* targets were removed from TARGETS variable and
placed in the TARGETS_ROOTFS variable so to fix the issue use use both
"TARGETS" and "TARGETS_ROOTFS" variables.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Vincent Stehlé <vincent.stehle@freescale.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The package infrastructure add automatically the "dirs" dependency so
remove it when the package infrastructure is being used.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot toolchain creates big endian binaries instead of little endian
ones for microblaze architecture. The reason is wrong BR2_ARCH string.
KERNEL_ARCH must contain microblaze in both cases.
Signed-off-by: Jan Drazil <xdrazi00@stud.fit.vutbr.cz>
Signed-off-by: Jan Viktorin <xvikto03@stud.fit.vutbr.cz>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the migration of the toolchains to the generic package
infrastructure, it is no longer used.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Because now the toolchain dependency is automatically added by the
package infrastructure the BASE_TARGETS variable is useless so just
remove it.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The parallel build patch series has significantly reworked how some of
the core dependencies are expressed. We now have the following
dependencies:
all: world
world: target-post-image
target-post-image: $(TARGETS_ROOTFS)
with TARGETS_ROOTFS containing the list of root filesystem image
targets, each having the following dependencies:
$$(BINARIES_DIR)/rootfs.$(1): target-finalize $$(ROOTFS_$(2)_DEPENDENCIES)
The bottom line is that the "target-finalize" target, which in turns
ensures that all packages are built, is only triggered if at least one
filesystem image is enabled.
As we want to support builds with no filesystem image selected, this
is not acceptable. As a fix, we change the target-post-image target
to:
target-post-image: $(TARGETS_ROOTFS) target-finalize
This way, target-finalize will be triggered even if TARGETS_ROOTFS is
empty. This is still correct for parallel build, as the individual
root filesystem image targets still depend on target-finalize.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Rename the GRAPH_OUT and GRAPH_ALT variables according to our
recently-agreed naming scheme for user-facing variables:
- GRAPH_OUT -> BR2_GRAPH_OUT
- GRAPH_ALT -> BR2_GRAPH_ALT
The documentation part of the rename is handled by Thomas as
part of his manual fixing spree. ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Using a relative path for BR2_EXTERNAL, and using an external defconfig,
such as in (from a Buildroot top-dir):
make O=.. BR2_EXTERNAL=.. foo_defconfig
is broken. It is unclear why the %_defconfig rule recurses in that case.
This patch internaly makes BR2_EXTERNAL canonical (ie. makes it an absolute
path), and checks the directory exists.
[Peter: s/relatively/relative/ as suggested by Thomas]
Reported-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix a bug introduced by the commit a24877586a
(Makefile: add support for top-level parallel make).
That commit put a new rule inside the target-finalize rule so it was
erroneously splitted in two parts.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The main Buildroot Makefile was removing *.py or *.pyc if Python 2 was
enabled, but for Python 3, this action was taken care of by a post
install target hook of python3.mk, which means it wouldn't work with
external modules (the .py/.pyc removal would be done before external
Python modules are installed).
We fix this by making the global *.py/*.pyc removal in the main
Makefile work for both Python 2 and Python 3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After the latest patches top-level parallel Makefile is working but
there is still an issue when a package has an unspecified optional
dependency so change the comment to explain that.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be able to use top-level parallel make we must not depend in a rule
on the order of evaluation of the prerequisites, so instead of relyng on
the left to right ordering of evaluation of the prerequisites add an
explicit rule to describe the dependencies.
Add explicit rules to describe the following dependency chain:
$(TARGETS) -> target-finalize -> rootfs-* -> target-post-image
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
inner-generic-package right after the configuration phase, example:
make clean <package-name>
Also remove TARGETS_ALL because the only purpose was to add toolchain
dependency so it's superseded by this commit.
To prevent circular dependency add the new variable
<pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain
dependency for toolchain packages.
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As the e-mail address buildroot@buildroot.org is now enabled, update the
e-mail addresses in the source tree from @uclibc.org and @busybox.net to our
own proper domain.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To make the naming consistent (all user-visible options should be
prefixed with BR2_).
An entry is added to Makefile.legacy to warn users who have set
BUILDROOT_CONFIG but not BR2_CONFIG.
Still export BUILDROOT_CONFIG but pointing to some phony value, to
make sure that scripts that still use it fail in a predictable way.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To make the naming consistent (all user-visible options should be
prefixed BR2_).
An entry is added to Makefile.legacy to warn users who have set
BUILDROOT_DL_DIR but not BR2_DL_DIR.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch removes deprecated symbol BR2_HAVE_DOCUMENTATION and all its
usage. Additionally, it removes the now unused BR2_DEPRECATED_SINCE_2012_11.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To make the naming consistent (qstripped variant of a config option
should be named BR_XXX).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current stripping strategy requires that shared libraries have the
executable permission. However, this is by far not something
recognized as a standard behavior: Debian/Ubuntu distributions for
example do not have executable permissions on their
libraries. Therefore, pushing to upstream packages fixes that add the
executable permissions is not easy.
As a result, this commit improves the stripping logic so that it not
only strips the files that are executable, but also the ones that
match '*.so*', which should match both the shared libraries and the
dlopen()'able plugins, as long as they have a .so extension.
Thanks to this addition, a number of manual "chmod +x" done by various
packages can be removed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If two files with the same relative paths exist in multiple overlay
skeletons, and they have the same modification time and size, then rsync
might not copy the later file on top of the earlier file. This patch fixes
this by adding the -I option to the rsync commands used in the overlay
skeleton file installations. ("man rsync" indicates that this option turns
off the file-size/mod-date "quick check" behavior, causing all files to be
updated - more like the cp commands that we had originally.)
[Peter: use --ignore-times to make it obvious what the option does]
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages install locales to /usr/lib/locale.
Parse and purge unneeded ones there too.
Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If the Buildroot tree is read-only, then $(TARGET_DIR_WARNING_FILE) is
copied read-only into target/ but we may want to remove it during the
build process.
This poses no real problem, since target/ itself is guaranteed to be
writable, but for good measure, force $(TARGET_DIR_WARNING_FILE) to be
writable itself.
Reported-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If the source target skeleton is read-only (eg. because Buildroot's
source dir is), modifications to the output target (such as creating
/etc/hostname and /etc/issue) fail.
(This can happen if the Buildroot source dir is NFS-mounted read-only
to be shared between different machines, for example).
Signed-off-by: Nathan Lynch <ntl@pobox.com>
[yann.morin.1998@free.fr: we use rsync now, not cp; --chmod=Du+w
suggested by Arnout; clarify commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GNU tar > 1.13.17 interprets TAR_OPTIONS as an environment variable
containing options to be prepended to the set on the command line.
Since we use the same variable, if the user's environment already
contains TAR_OPTIONS, our use of the same variable name modifies
the environment and causes untars to misbehave when TAR_OPTIONS
causes a -xf to be prepended to the tar command line, likely
converting a subsequent flag into a spurious filename.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 94dd02f5d0.
The change breaks defconfigs from BR2_EXTERNAL, both for in-tree and
out-of-tree builds.
Besides, the problem reported in 94dd02f could not be reproduced.
I can read French, and I suspect a relative path was used for either
BR2_EXTERNAL or O.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jérémy Rosen <jeremy.rosen@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
PDF files can not be easily embedded in other documents (eg. ODT, or HTML).
Add support for generating PNG graphs, by setting the GRAPH_OUT=pdf|png on
the command line:
make GRAPH_OUT=png graph-build graph-depends
The default is still to generate PDF graphs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Generate the graph of the complete dependency tree by calling:
make graph-depends
It's also possible to generate the graph-depends for a single package:
make PKG-graph-depends
The graphs are generated in $(O)/graphs/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Generate the build-time graphs by calling:
make graph-build
This generates the graphs in $(O)/graphs/
It is possible to use the alternate color-scheme by setting the variable
GRAPH_ALT=1 on the command line:
make GRAPH_ALT=1 graph-build
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, we do not include .config for all '%_defconfig' targets, but
we forgot to also exclude plain 'defconfig'.
Reported-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The source-check / external-deps make targets ends up calling recursively
into buildroot's Makefile, causing make to display a warning:
make[2]: warning: -jN forced in submake: disabling jobserver mode.
We don't support toplevel parallel make, so get rid of the warning using
MAKE1 instead.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit allows the user to store defconfigs in
$BR2_EXTERNAL/configs/. To achieve this:
* It adds a new %_defconfig that looks in $BR2_EXTERNAL/configs/ for
the corresponding defconfig file.
* Updates the help target to also list external defconfigs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Ryan Barnett <rjbarnet@rockwellcollins.com>
Tested-by: "Samuel Martin" <s.martin49@gmail.com>
Acked-by: "Samuel Martin" <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>