Currently, we do nothing about packages that touch the same file: given
a specific configuration, the result is reproducible (even though it
might not be what the user expected) because the build order is
guaranteed.
However, when we later introduce top-level parallel build, we will no
longer be able to guarantee a build order, by the mere way of it being
parallel. Reconciliating all those modified files will be impossible to
do automatically. The only way will be to refuse such situations.
As a preliminary step, introduce a helper script that detects files that
are being moified by two or more packages, and reports them and the
impacted packages, at the end of the build.
The list being reported at the end of the build will make it prominently
visible in autobuilder results, so we can assess the problem, if any.
Later on, calling that helper script can be done right after the package
installation step, to bail out early.
Thanks Arnout for the pythonist way to write default dictionaries! ;-)
Note: doing it in python rather than a shell script is impressively
faster: where the shell script takes ~1.2s on a minimalist build, the
python script only takes ~0.015s, that is about 80 times faster.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Peter Seiderer <ps.report@gmx.net>
[Thomas: rename script without .py extension.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
SOURCE_DATE_EPOCH is currently forcibly set (to either the git commit
date, or the last release date).
However, the spec mandates that it should not be modified if already
set: https://reproducible-builds.org/specs/source-date-epoch/
Build systems MUST NOT overwrite this variable for child
processes to consume if it is already present.
Abide by the rule, and only set it if not already set.
This will allow users to pass it from an upper-layer buildsystem (e.g. a
jenkins or gitlab-ci job, for example), when they have a reson to do so.
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Reported-by: Einar Jón Gunnarsson <tolvupostur@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Einar Jón Gunnarsson <tolvupostur@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
That way packages included in that list like ccache will also be
regarded as a normal packages for targets like external-deps,
show-targets or legal-info
Signed-off-by: Alfredo Alvarez Fernandez <alfredo.alvarez_fernandez@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
It is used by Kconfig's merge_config.sh.
No alldefpackageconfig is added, since it's rather pointless: it would
only enable busybox.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The rules for the *config targets are all very similar, so factor them
together using $@.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some macros, soon some variables, currently defined in the skeleton are
going to be used by other packages.
Some of those variables will be used as Makefile conditions (e.g. in
ifeq() conditions), so they *must* be defined before being used.
Since the skeleton package, starting with an 's', is included quite
late, those variables would not be available to most packages.
Offload the existing macros into the new system/system.mk file, that is
included early, before any package is. Rename the macros to appropriate
names.
Future commits will add new macros and variables in that file.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We use a separate make target to build a relocatable SDK. We first
sanitize the RPATH in host tree. Next we also sanitize the
staging tree. Therefore "sdk" must depend on world.
Sanitizing staging is not really needed, in the sense that any rpath
in there is simply not going to be used. We want to sanitize staging
for the following reasons:
- To avoid leaking references to the original output directory. This
way, we can validate that the SDK is relocatable by running a simple
"grep -r ${BASE_DIR} ${HOST_DIR}". Obviously RPATH sanitization is
not sufficient (e.g. also the references to source files have to be
stripped), but it's a step in the right direction. This reason is
obviously only relevant for the SDK.
- To make sure that when an executable is copied to target that it
actually executes correctly. Since within Buildroot we never copy
stuff from staging to target, this is clearly only relevant for
the SDK.
Finally we install the script "relocate-sdk.sh" into the top directory
of the SDK (HOST_DIR) and the SDK location path is stored in the file
"HOST_DIR/share/buildroot/sdk-location"-
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We sanitize the RPATH of ELF files in the target tree to deal
with stupid packages that don't correctly use --prefix/DESTDIR
and that end up putting the full absolute build-time directory
in the RPATH.
We do it before copying the overlay and calling the post-build
script. The user is completely responsible for what happens
in the last two steps, and it should never be touched by us.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Up to now we created the $(HOST_DIR)/usr compatibility symlink as part
of the creation of $(HOST_DIR) itself. However, when the user specifies
a custom BR2_HOST_DIR, it is possible that the directory already exists
so this rule will never trigger.
Therefore, add an explicit rule for creating $(HOST_DIR)/usr and add
this rule to the dependencies of the dirs target. HOST_DIR itself goes
back to the standard rule for directories. The order-only dependency of
STAGING_DIR isn't needed any more either: HOST_DIR is implicitly
created if needed by mkdir -p, and we don't need to trigger the
HOST_DIR rule any more if the directory already exists.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This silences the annoying warning that there is no hash file for our
own COPYING file.
Also change the message so that it is more obvious what we're doing.
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now $(HOST_DIR)/usr is a symlink to $(HOST_DIR), it makes no sense to
still have it in BR_PATH.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We currently use $(HOST_DIR)/usr as the prefix for host packages. That
has a few disadvantages:
- There are some things installed in $(HOST_DIR)/etc and
$(HOST_DIR)/sbin, which is inconsistent.
- To pack a buildroot-built toolchain into a tarball for use as an
external toolchain, you have to pack output/host/usr instead of the
more obvious output/host.
- Because of the above, the internal toolchain wrapper breaks which
forces us to work around it (call the actual toolchain executable
directly). This is OK for us, but when used in another build system,
that's a problem.
- Paths are four characters longer.
To allow us to gradually eliminate $(HOST_DIR)/usr while building
packages, replace it with a symlink to .
The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and
$(HOST_DIR)/usr/lib that were added previously are removed again.
Note that the symlink creation will break when $(HOST_DIR)/usr
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
At the same time as creating this symlink, we have to update the
external toolchain wrapper and the external toolchain symlinks to go
one directory less up. Indeed, $(HOST_DIR) is one level less up than
it was before.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a step towards eliminating $(HOST_DIR)/usr. It allows us to
convert all packages installing things into $(HOST_DIR)/usr/lib without
affecting the rest.
To allow compatibility with packages that still use $(HOST_DIR)/usr as
the prefix, create a symlink from usr/lib to ../lib.
Note that the symlink creation will break when $(HOST_DIR)/usr/lib
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
At the same time as creating this symlink, we also have to update the
check-host-rpath script to accept both $(HOST_DIR)/usr/lib and
$(HOST_DIR)/lib, because depending on how the package derives the
path, it may be different.
Since there are some dependency chains that involve $(STAGING_DIR),
$(STAGING_DIR) may in fact be created before $(HOST_DIR). Since
$(STAGING_DIR) is a subdirectory of $(HOST_DIR), it is possible that the
newly added rule for $(HOST_DIR) never triggers. To make sure that the
rule does trigger, add an order-only dependency from $(STAGING_DIR) to
$(HOST_DIR).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a step towards eliminating $(HOST_DIR)/usr. It allows us to
convert all packages installing things into
$(HOST_DIR)/usr/$(GNU_TARGET_NAME) (i.e., binutils and gcc) without
affecting the rest.
To allow compatibility with packages that still use $(HOST_DIR)/usr as
the prefix, create a symlink from usr/$(GNU_TARGET_NAME) to
../$(GNU_TARGET_NAME).
Note that the symlink creation will break when $(HOST_DIR)/usr/lib
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
Effectively, the usr/ part is removed from $(STAGING_SUBDIR) (and
therefore from $(STAGING_DIR)), so update the definition of that
variable right away.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This will be useful when checking the hashes of the license files.
[Peter: use '.' as buildroot directory so /buildroot.hash isn't checked]
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>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The recent change to error out instead of running menuconfig when no .config
is available broke an existing use case:
make O=output-foo; cd output-foo; br-init-conf (or similar to get a sensible .config); make
As there is no wrapper makefile in output-foo.
Fix it by ensuring the wrapper gets created if needed.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit improves our .gitlab-ci.yml logic to execute our runtime
tests located in support/testing/. To do so, this commit:
- Adds more Debian packages to be installed, namely the nose2 and
pexpect packages needed by the runtime testing infrastructure, as
well as the necessary Qemu emulators
- The description of how to run the runtime tests. Each test is
executed as a separate Gitlab CI job, so that the status of each
test is easily visible in the Gitlab CI web interface.
- The Makefile is improved to auto-generate .gitlab-ci.yml from
.gitlab-ci.yml.in, like we're doing for defconfigs. Since the
dependencies of .gitlab-ci.yml are no longer correct, we abandon
them and instead make it a PHONY target.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Arnout: simplify .gitlab-ci.in a little, removing redundant stuff;
make .gitlab-ci.yml a PHONY target]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since forever, we run 'menuconfig' automatically on an unconfigured
tree. However, this does not help users that much:
- If they read the documentation, they should already know to run
make menuconfig first.
- If they haven't read the documentation, dropping them in menuconfig
isn't very helpful.
- It's a likely that the user didn't intend to be in an unconfigured
tree (e.g. wrong O= specified), so starting menuconfig (and polluting
this wrong O= directory) is not very helpful.
- It's possible that the user really doesn't want menuconfig, but
instead needs xconfig, or some defconfig, or ...
So, instead of trying to guess what the user needs, print an error and
let the user decide what to do next.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by Alessandro Power on StackOverflow [1], the behaviour
of "make toolchain" in an unconfigured tree is misleading.
When .config doesn't exist, we don't read in the package .mk files, so
"make <package>" doesn't work:
$ make busybox
make: *** No rule to make target 'busybox'. Stop.
However, for "linux" and "toolchain", the corresponding file (or
actually directory) already exists. So instead, we get:
$ make linux
make: Nothing to be done for 'linux'.
This is confusing, because it looks as if the build succeeded.
The obvious solution is to make linux and toolchain PHONY targets when
.config doesn't exist. However, that actually does the reverse, because
then a rule _does_ exist for them and since they don't have
dependencies, make will consider them to be ready.
Therefore, we also have to provide an explicit rule for them, and
explicitly error out. Thise behaviour is still different from other
packages, but at least it is much less confusing.
[1] https://stackoverflow.com/questions/44521150
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When calling 'make printvars' without -s, it ends with
"Nothing to be done for 'printvars'." That's because the rule only
contains $(info ...) calls and no actual shell commands to execute.
To avoid this, make sure there is a shell command by adding :.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Quite a few targets in the top-level Makefile were missing the .PHONY
marking. Now that the .PHONY declarations are next to the definition
of the targets, they are much easier to find.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, a lot of targets are declared PHONY together in the middle
of the Makefile. This has two important shortcomings:
- it is more difficult to see if a target is missing from PHONY;
- it is currently inside the ifeq ($(BR2_HAVE_DOT_CONFIG),y) condition,
but some of these targets are also defined when there is no .config;
in that case, these targets are not declared as PHONY.
Both issues can easily be solved by putting the PHONY declaration next
to the definition of the target.
The noconfig_targets are also all declared PHONY together; however,
for these we anyway have to keep the noconfig_targets variable
up-to-date, and that PHONY declaration is outside all conditions, so
there is no benefit of splitting them.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This simplifies the variable a little
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain is a package, so it is already defined as .PHONY in the
inner-generic-package macro.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When debugging hidden dependencies, the build order is very important.
Most notably, it is interesting to identify potential culprits.
Add a new top-level rule, show-biuld-order, that dumps all the packages
in the order they would get built.
Note that there are a few differences with show-targets:
- more packages are reported, becasue show-targets does not report
host packages that have no prompt;
- the output is line-based, because we're using $(info $(1)); getting
a single output line like show-targets would require we use an
actual command, like printf '%s ' $(1); but that takes a lot of
time, while $(info $(1)) is almost instantaneous (the time to parse
the Makefiles);
- rootfs targets are not reported.
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>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
Allow architectures to define variables and helper macros.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The buildroot repository is now mirrored on
https://gitlab.com/buildroot.org/buildroot so we can use Gitlab-CI to
test Buildroot. Gitlab-CI is controlled by a .gitlab-ci.yml file
that exists in the repository.
For now, the only test is building all defconfigs (inspired on
https://travis-ci.org/buildroot/buildroot-defconfig-testing/). Since
all the defconfigs have to be specified in the .gitlab-ci.yml file,
we generate the file based on .gitlab-ci.yml.in. The generated
.gitlab-ci.yml file has to be committed into the repository, though,
otherwise Gitlab-CI doesn't see it. So there is also a test to verify
that .gitlab-ci.yml is up-to-date.
Building all the defconfigs takes a long time. Gitlab-CI will do that
every time it pulls from git.buildroot.org, which is once per hour.
That is way too often. Therefore, the defconfigs are not built on pull,
but only on explicit trigger through the API or when a tag is added.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
- fix typo not -> no
- add LC_ALL=C when calling 'ls -1' to get a predictable order of the
defconfigs
- regenerate .gitlab-ci.yml.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit teaches the generic package handling code how to extract .tar.lz
archives. When lzip is not installed on the host, host-lzip gets built
automatically.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When GCC_COLORS is set, ccache passes '-fdiagnostics-color' to GCC but
this flag requires GCC v4.9 or later. Older versions complain about the
unrecognized command line option.
Using GCC_COLORS in the context of Buildroot is seldom useful, so we
just unexport GCC_COLORS altogether.
Reported-by: Carlos Santos <casantos@datacom.ind.br>
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: Peter Korsgaard <peter@korsgaard.com>
