2013-09-05 09:12:15 +02:00
|
|
|
# Makefile for buildroot
|
2001-12-22 01:56:11 +01:00
|
|
|
#
|
2023-01-13 08:53:48 +01:00
|
|
|
# Copyright (C) the Buildroot developers <buildroot@buildroot.org>
|
2001-12-22 01:56:11 +01:00
|
|
|
#
|
2002-04-26 13:45:55 +02:00
|
|
|
# This program is free software; you can redistribute it and/or modify
|
2004-10-09 03:06:03 +02:00
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
# (at your option) any later version.
|
2001-12-22 01:56:11 +01:00
|
|
|
#
|
2004-10-09 03:06:03 +02:00
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
2002-04-26 13:45:55 +02:00
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
2004-10-09 03:06:03 +02:00
|
|
|
# General Public License for more details.
|
2009-01-26 20:42:47 +01:00
|
|
|
#
|
2004-10-09 03:06:03 +02:00
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
|
# along with this program; if not, write to the Free Software
|
|
|
|
|
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
2004-09-03 02:49:43 +02:00
|
|
|
#
|
2003-10-18 13:09:54 +02:00
|
|
|
|
2004-10-09 03:06:03 +02:00
|
|
|
#--------------------------------------------------------------
|
|
|
|
|
# Just run 'make menuconfig', configure stuff, then run 'make'.
|
|
|
|
|
# You shouldn't need to mess with anything beyond this point...
|
|
|
|
|
#--------------------------------------------------------------
|
2010-10-31 17:35:09 +01:00
|
|
|
|
2016-11-05 22:05:08 +01:00
|
|
|
# Delete default rules. We don't use them. This saves a bit of time.
|
|
|
|
|
.SUFFIXES:
|
|
|
|
|
|
2016-06-19 06:12:06 +02:00
|
|
|
# we want bash as shell
|
|
|
|
|
SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
|
|
|
|
|
else if [ -x /bin/bash ]; then echo /bin/bash; \
|
|
|
|
|
else echo sh; fi; fi)
|
|
|
|
|
|
2016-10-17 23:05:42 +02:00
|
|
|
# Set O variable if not already done on the command line;
|
|
|
|
|
# or avoid confusing packages that can use the O=<dir> syntax for out-of-tree
|
|
|
|
|
# build by preventing it from being forwarded to sub-make calls.
|
|
|
|
|
ifneq ("$(origin O)", "command line")
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
O := $(CURDIR)/output
|
2016-10-17 23:05:42 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Check if the current Buildroot execution meets all the pre-requisites.
|
|
|
|
|
# If they are not met, Buildroot will actually do its job in a sub-make meeting
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
# its pre-requisites, which are:
|
2016-10-17 23:05:42 +02:00
|
|
|
# 1- Permissive enough umask:
|
|
|
|
|
# Wrong or too restrictive umask will prevent Buildroot and packages from
|
|
|
|
|
# creating files and directories.
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
# 2- Absolute canonical CWD (i.e. $(CURDIR)):
|
|
|
|
|
# Otherwise, some packages will use CWD as-is, others will compute its
|
|
|
|
|
# absolute canonical path. This makes harder tracking and fixing host
|
|
|
|
|
# machine path leaks.
|
|
|
|
|
# 3- Absolute canonical output location (i.e. $(O)):
|
|
|
|
|
# For the same reason as the one for CWD.
|
|
|
|
|
|
|
|
|
|
# Remove the trailing '/.' from $(O) as it can be added by the makefile wrapper
|
|
|
|
|
# installed in the $(O) directory.
|
|
|
|
|
# Also remove the trailing '/' the user can set when on the command line.
|
|
|
|
|
override O := $(patsubst %/,%,$(patsubst %.,%,$(O)))
|
|
|
|
|
# Make sure $(O) actually exists before calling realpath on it; this is to
|
|
|
|
|
# avoid empty CANONICAL_O in case on non-existing entry.
|
|
|
|
|
CANONICAL_O := $(shell mkdir -p $(O) >/dev/null 2>&1)$(realpath $(O))
|
|
|
|
|
|
2018-08-20 22:49:53 +02:00
|
|
|
# gcc fails to build when the srcdir contains a '@'
|
|
|
|
|
ifneq ($(findstring @,$(CANONICAL_O)),)
|
|
|
|
|
$(error The build directory can not contain a '@')
|
|
|
|
|
endif
|
|
|
|
|
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
CANONICAL_CURDIR = $(realpath $(CURDIR))
|
2016-10-17 23:05:42 +02:00
|
|
|
|
|
|
|
|
REQ_UMASK = 0022
|
|
|
|
|
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
# Make sure O= is passed (with its absolute canonical path) everywhere the
|
|
|
|
|
# toplevel makefile is called back.
|
|
|
|
|
EXTRAMAKEARGS := O=$(CANONICAL_O)
|
2016-10-17 23:05:42 +02:00
|
|
|
|
|
|
|
|
# Check Buildroot execution pre-requisites here.
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
ifneq ($(shell umask):$(CURDIR):$(O),$(REQ_UMASK):$(CANONICAL_CURDIR):$(CANONICAL_O))
|
2015-07-17 00:33:07 +02:00
|
|
|
.PHONY: _all $(MAKECMDGOALS)
|
2014-11-21 17:19:00 +01:00
|
|
|
|
2015-07-17 00:33:07 +02:00
|
|
|
$(MAKECMDGOALS): _all
|
|
|
|
|
@:
|
2014-11-21 17:19:00 +01:00
|
|
|
|
2015-07-17 00:33:07 +02:00
|
|
|
_all:
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
@umask $(REQ_UMASK) && \
|
|
|
|
|
$(MAKE) -C $(CANONICAL_CURDIR) --no-print-directory \
|
|
|
|
|
$(MAKECMDGOALS) $(EXTRAMAKEARGS)
|
2014-11-21 17:19:00 +01:00
|
|
|
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
else # umask / $(CURDIR) / $(O)
|
2014-11-21 17:19:00 +01:00
|
|
|
|
2014-10-11 19:34:42 +02:00
|
|
|
# This is our default rule, so must come first
|
|
|
|
|
all:
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: all
|
2014-10-11 19:34:42 +02:00
|
|
|
|
2010-10-31 17:35:10 +01:00
|
|
|
# Set and export the version string
|
2023-11-14 08:25:01 +01:00
|
|
|
export BR2_VERSION := 2023.11-rc1
|
2016-11-23 13:58:40 +01:00
|
|
|
# Actual time the release is cut (for reproducible builds)
|
2023-11-14 08:25:01 +01:00
|
|
|
BR2_VERSION_EPOCH = 1699946000
|
2010-10-31 17:35:10 +01:00
|
|
|
|
2015-07-14 23:30:39 +02:00
|
|
|
# Save running make version since it's clobbered by the make package
|
|
|
|
|
RUNNING_MAKE_VERSION := $(MAKE_VERSION)
|
|
|
|
|
|
2012-02-08 17:22:17 +01:00
|
|
|
# Check for minimal make version (note: this check will break at make 10.x)
|
2014-04-23 10:39:23 +02:00
|
|
|
MIN_MAKE_VERSION = 3.81
|
2015-07-14 23:30:39 +02:00
|
|
|
ifneq ($(firstword $(sort $(RUNNING_MAKE_VERSION) $(MIN_MAKE_VERSION))),$(MIN_MAKE_VERSION))
|
|
|
|
|
$(error You have make '$(RUNNING_MAKE_VERSION)' installed. GNU make >= $(MIN_MAKE_VERSION) is required)
|
2012-02-08 17:22:17 +01:00
|
|
|
endif
|
|
|
|
|
|
2009-11-30 17:29:01 +01:00
|
|
|
# absolute path
|
2016-03-09 23:58:43 +01:00
|
|
|
TOPDIR := $(CURDIR)
|
2014-04-23 10:39:23 +02:00
|
|
|
CONFIG_CONFIG_IN = Config.in
|
|
|
|
|
CONFIG = support/kconfig
|
|
|
|
|
DATE := $(shell date +%Y%m%d)
|
2003-09-26 23:18:46 +02:00
|
|
|
|
2010-10-31 17:35:12 +01:00
|
|
|
# Compute the full local version string so packages can use it as-is
|
|
|
|
|
# Need to export it, so it can be got from environment in children (eg. mconf)
|
Makefile: properly account for custom tags in BR2_VERSION_FULL
BR2_VERSION_FULL is currently defined as follows:
BR2_VERSION_FULL := $(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
This BR2_VERSION_FULL value then gets used as the "VERSION" variable
in the /etc/os-release file.
The logic of "setlocalversion" is that if it is exactly on a tag, it
returns nothing.
If it is on a tag + a number of commits, then it returns only
-XYZ-gABC where XYZ is the number of commits since the last tag, and
ABC the git commit hash (these are extracted from git describe).
This output then gets concatenated to BR2_VERSION which gives
something like 2020.05 or 2020.05-00123-g5bc6a.
The issue is that when you're on a tag specific to your project, which
is not a Buildroot YYYY.MM tag, then the output of setlocalversion is
empty, and all you get as VERSION in os-release is $(BR2_VERSION)
which is not really nice. Worse, if you have another non-official
Buildroot tag between the last official Buildroot tag/version and
where you are, you will get $(BR2_VERSION)-XYZ-gABC, but XYZ will not
correspond to the number of commits since BR2_VERSION, but since the
last tag that "git describe" as found, which is clearly incorrect.
Here is an example: you're on master, "make print-version" (which
displays BR2_VERSION_FULL) will show:
$ make print-version
2020.08-git-00758-gc351877a6e
So far so good. Now, you create a tag say 5 commits "before" master,
and show BR2_VERSION_FULL again:
$ git tag -a -m "dummy tag" dummy-tag HEAD~5
$ make print-version
2020.08-git-00005-gc351877a6e
This makes you believe you are 5 commits above 2020.08, which is
absolutely wrong.
So this commit simplifies the logic of setlocalversion to simply
return what "git describe" provides, and not prepend $(BR2_VERSION) in
the main Makefile. Since official Buildroot tags match official
Buildroot version names, you get the same output when you're on an
official Buildroot tag, or some commits above a Buildroot tag. An in
other cases, you get a sensible output. The logic is also adjusted for
the Mercurial case.
In the above situation, with this commit applied, we get:
$ make print-version
dummy-tag-6-g6258cdddeb
(6 commits instead of 5 as we have this very commit applied, but at
least it's 6 commits on top of the dummy-tag)
Finally, if you're not using a version control system, setlocalversion
was already returning nothing, so in this case, the Makefile simply
sets BR2_VERSION_FULL to BR2_VERSION to preserve this behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-07-20 13:59:57 +02:00
|
|
|
|
|
|
|
|
BR2_LOCALVERSION := $(shell $(TOPDIR)/support/scripts/setlocalversion)
|
|
|
|
|
ifeq ($(BR2_LOCALVERSION),)
|
|
|
|
|
export BR2_VERSION_FULL := $(BR2_VERSION)
|
|
|
|
|
else
|
|
|
|
|
export BR2_VERSION_FULL := $(BR2_LOCALVERSION)
|
|
|
|
|
endif
|
2010-10-31 17:35:12 +01:00
|
|
|
|
2017-06-15 00:11:29 +02:00
|
|
|
# List of targets and target patterns for which .config doesn't need to be read in
|
2014-04-23 10:39:23 +02:00
|
|
|
noconfig_targets := menuconfig nconfig gconfig xconfig config oldconfig randconfig \
|
2018-09-19 13:36:15 +02:00
|
|
|
defconfig %_defconfig allyesconfig allnoconfig alldefconfig syncconfig release \
|
2009-10-04 21:57:12 +02:00
|
|
|
randpackageconfig allyespackageconfig allnopackageconfig \
|
2022-07-31 21:35:18 +02:00
|
|
|
print-version olddefconfig distclean manual manual-% check-package
|
2006-12-02 20:01:10 +01:00
|
|
|
|
2015-04-26 11:51:14 +02:00
|
|
|
# Some global targets do not trigger a build, but are used to collect
|
|
|
|
|
# metadata, or do various checks. When such targets are triggered,
|
|
|
|
|
# some packages should not do their configuration sanity
|
|
|
|
|
# checks. Provide them a BR_BUILDING variable set to 'y' when we're
|
|
|
|
|
# actually building and they should do their sanity checks.
|
|
|
|
|
#
|
|
|
|
|
# We're building in two situations: when MAKECMDGOALS is empty
|
|
|
|
|
# (default target is to build), or when MAKECMDGOALS contains
|
|
|
|
|
# something else than one of the nobuild_targets.
|
2017-10-25 22:09:51 +02:00
|
|
|
nobuild_targets := source %-source \
|
2016-11-15 12:03:20 +01:00
|
|
|
legal-info %-legal-info external-deps _external-deps \
|
|
|
|
|
clean distclean help show-targets graph-depends \
|
|
|
|
|
%-graph-depends %-show-depends %-show-version \
|
|
|
|
|
graph-build graph-size list-defconfigs \
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
savedefconfig update-defconfig printvars show-vars
|
2015-04-26 11:51:14 +02:00
|
|
|
ifeq ($(MAKECMDGOALS),)
|
|
|
|
|
BR_BUILDING = y
|
|
|
|
|
else ifneq ($(filter-out $(nobuild_targets),$(MAKECMDGOALS)),)
|
|
|
|
|
BR_BUILDING = y
|
|
|
|
|
endif
|
|
|
|
|
|
2016-11-03 02:55:16 +01:00
|
|
|
# We call make recursively to build packages. The command-line overrides that
|
|
|
|
|
# are passed to Buildroot don't apply to those package build systems. In
|
|
|
|
|
# particular, we don't want to pass down the O=<dir> option for out-of-tree
|
|
|
|
|
# builds, because the value specified on the command line will not be correct
|
|
|
|
|
# for packages.
|
|
|
|
|
MAKEOVERRIDES :=
|
|
|
|
|
|
2016-07-17 12:34:21 +02:00
|
|
|
# Include some helper macros and variables
|
|
|
|
|
include support/misc/utils.mk
|
2009-01-25 21:19:01 +01:00
|
|
|
|
2016-10-17 23:05:41 +02:00
|
|
|
# Set variables related to in-tree or out-of-tree build.
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
# Here, both $(O) and $(CURDIR) are absolute canonical paths.
|
|
|
|
|
ifeq ($(O),$(CURDIR)/output)
|
|
|
|
|
CONFIG_DIR := $(CURDIR)
|
2016-10-17 23:05:41 +02:00
|
|
|
NEED_WRAPPER =
|
|
|
|
|
else
|
|
|
|
|
CONFIG_DIR := $(O)
|
2014-04-23 10:39:23 +02:00
|
|
|
NEED_WRAPPER = y
|
2010-01-11 13:28:50 +01:00
|
|
|
endif
|
|
|
|
|
|
2013-10-02 22:06:40 +02:00
|
|
|
# bash prints the name of the directory on 'cd <dir>' if CDPATH is
|
|
|
|
|
# set, so unset it here to not cause problems. Notice that the export
|
2016-11-23 03:31:31 +01:00
|
|
|
# line doesn't affect the environment of $(shell ..) calls.
|
2014-04-23 10:39:23 +02:00
|
|
|
export CDPATH :=
|
2016-11-23 03:31:31 +01:00
|
|
|
|
|
|
|
|
BASE_DIR := $(CANONICAL_O)
|
2013-10-02 22:06:40 +02:00
|
|
|
$(if $(BASE_DIR),, $(error output directory "$(O)" does not exist))
|
|
|
|
|
|
core: introduce the BR2_EXTERNAL variable
This commit introduces the BR2_EXTERNAL environment variable, which
will allow to keep Buildroot customization (board-specific
configuration files or root filesystem overlays, package Config.in and
makefiles, as well as defconfigs) outside of the Buildroot tree.
This commit only introduces the variable itself, and ensures that it
is available within Config.in options. This allows us to use
$BR2_EXTERNAL in a 'source' statement in Config.in.
Following patches extend the usage of BR2_EXTERNAL to other areas
(packages and defconfigs).
In details, this commit:
* Introduces the BR2_EXTERNAL Kconfig option. This option has no
prompt, and is therefore not visible to the user and also not
stored in the .config file. It is automatically set to the value of
the BR2_EXTERNAL environment variable. The only purpose of this
BR2_EXTERNAL Kconfig option is to allow $BR2_EXTERNAL to be
properly expanded when used inside Kconfig source statements.
* Calculates the BR2_EXTERNAL value to use. If passed on the command
line, then this value is taken in priority, and saved to a
.br-external hidden file in the output directory. If not passed on
the command line, then we read the .br-external file from the
output directory. This allows the user to not pass the BR2_EXTERNAL
value at each make invocation. If no BR2_EXTERNAL value is passed,
we define it to support/dummy-external, so that the kconfig code
finds an existing $(BR2_EXTERNAL)/package/Config.in file to
include.
* Passes the BR2_EXTERNAL into the *config environment, so that its
value is found when parsing/evaluating Config.in files and .config
values.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
2013-12-05 20:11:10 +01:00
|
|
|
|
|
|
|
|
# Handling of BR2_EXTERNAL.
|
|
|
|
|
#
|
|
|
|
|
# The value of BR2_EXTERNAL is stored in .br-external in the output directory.
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
# The location of the external.mk makefile fragments is computed in that file.
|
core: offload handling of BR2_EXTERNAL into the script
Currently, we treat the case where we have no br2-external tree
(BR2_EXTERNAL is empty) differently from the case where we do have one
(BR2_EXTERNAL is not empty).
There is now no reason to treat those two cases differently:
- the kconfig snippet is always generated appropriately (i.e. it would
include the br2-external tree if set, or include nothing otherwise);
- we no longer have a dummy br-external tree either.
Also, the Makefile code to handle BR2_EXTERNAL is currently quite
readable if at least a little bit tricky.
However, when we're going to add support for using multiple br2-external
trees simultaneously, this code would need to get much, much more complex.
To keep the Makefile (rather) simple, offload all of the handling of
BR2_EXTERNAL to the recently added br2-external helper script.
However, because of Makefiles idiosyncracies, we can't use a rule to
generate that Makefile fragment.
Instead, we use $(shell ...) to call the helper script, and include the
fragment twice: once before the $(shell ...) so we can grab a previously
defined BR2_EXTERNAL value, a second time to use the one passed on the
command line, if any.
Furthermore, we can't error out (e.g. on non-existent br2-external tree)
directly from the fragment or we'd get that error on subsequent calls,
with no chance to override it even from command line.
Instead, we use a variable in which we store the error, set it to empty
before the second inclusion, so that only the one newly generated, if
any, is taken into account.
Since we know the script will always be called from Makefile context
first, we know validation will occur in Makefile context first. So we
can assume that, if there is an error, it will be detected in Makefile
context. Consequently, if the script is called to generate the kconfig
fragment, validation has already occured, and there should be no error.
So we change the error function to generate Makefile code, so that
errors are caught as explained above.
Lastly, when the value of BR2_EXTERNAL changes, we want to 'forget'
about the previous value of the BR2_EXTERNAL_MK variable, especially in
the case where BR2_EXTERNAL is now set to empty, so that we do not try
to include it later. That's why we first generate empty version of
BR2_EXTERNAL_MK, and then assign it the new value, if any.
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: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:15 +02:00
|
|
|
# On subsequent invocations of make, this file is read in. BR2_EXTERNAL can
|
|
|
|
|
# still be overridden on the command line, therefore the file is re-created
|
|
|
|
|
# every time make is run.
|
core: introduce the BR2_EXTERNAL variable
This commit introduces the BR2_EXTERNAL environment variable, which
will allow to keep Buildroot customization (board-specific
configuration files or root filesystem overlays, package Config.in and
makefiles, as well as defconfigs) outside of the Buildroot tree.
This commit only introduces the variable itself, and ensures that it
is available within Config.in options. This allows us to use
$BR2_EXTERNAL in a 'source' statement in Config.in.
Following patches extend the usage of BR2_EXTERNAL to other areas
(packages and defconfigs).
In details, this commit:
* Introduces the BR2_EXTERNAL Kconfig option. This option has no
prompt, and is therefore not visible to the user and also not
stored in the .config file. It is automatically set to the value of
the BR2_EXTERNAL environment variable. The only purpose of this
BR2_EXTERNAL Kconfig option is to allow $BR2_EXTERNAL to be
properly expanded when used inside Kconfig source statements.
* Calculates the BR2_EXTERNAL value to use. If passed on the command
line, then this value is taken in priority, and saved to a
.br-external hidden file in the output directory. If not passed on
the command line, then we read the .br-external file from the
output directory. This allows the user to not pass the BR2_EXTERNAL
value at each make invocation. If no BR2_EXTERNAL value is passed,
we define it to support/dummy-external, so that the kconfig code
finds an existing $(BR2_EXTERNAL)/package/Config.in file to
include.
* Passes the BR2_EXTERNAL into the *config environment, so that its
value is found when parsing/evaluating Config.in files and .config
values.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
2013-12-05 20:11:10 +01:00
|
|
|
|
2019-07-29 22:19:54 +02:00
|
|
|
BR2_EXTERNAL_FILE = $(BASE_DIR)/.br2-external.mk
|
core: introduce the BR2_EXTERNAL variable
This commit introduces the BR2_EXTERNAL environment variable, which
will allow to keep Buildroot customization (board-specific
configuration files or root filesystem overlays, package Config.in and
makefiles, as well as defconfigs) outside of the Buildroot tree.
This commit only introduces the variable itself, and ensures that it
is available within Config.in options. This allows us to use
$BR2_EXTERNAL in a 'source' statement in Config.in.
Following patches extend the usage of BR2_EXTERNAL to other areas
(packages and defconfigs).
In details, this commit:
* Introduces the BR2_EXTERNAL Kconfig option. This option has no
prompt, and is therefore not visible to the user and also not
stored in the .config file. It is automatically set to the value of
the BR2_EXTERNAL environment variable. The only purpose of this
BR2_EXTERNAL Kconfig option is to allow $BR2_EXTERNAL to be
properly expanded when used inside Kconfig source statements.
* Calculates the BR2_EXTERNAL value to use. If passed on the command
line, then this value is taken in priority, and saved to a
.br-external hidden file in the output directory. If not passed on
the command line, then we read the .br-external file from the
output directory. This allows the user to not pass the BR2_EXTERNAL
value at each make invocation. If no BR2_EXTERNAL value is passed,
we define it to support/dummy-external, so that the kconfig code
finds an existing $(BR2_EXTERNAL)/package/Config.in file to
include.
* Passes the BR2_EXTERNAL into the *config environment, so that its
value is found when parsing/evaluating Config.in files and .config
values.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
2013-12-05 20:11:10 +01:00
|
|
|
-include $(BR2_EXTERNAL_FILE)
|
core: generate all br2-external files in one go
When we introduced support for multiple br2-external trees, we
introduced two files, one on the Makefile side, needed very early,
and one on the kconfig side, needed later in the configuration
process. We naturally introduced a two-step generation, as it looked
like the simplest and most obvious way.
But now, we are on the verge of generating more files on the kconfig
side, and it does not make sense to add even more steps to generate
them.
And even better yet, we can generate both the Makefile-side and
kconfig-side files at the same time, in fact.
Make it so.
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>
2019-07-29 22:19:56 +02:00
|
|
|
$(shell support/scripts/br2-external -d '$(BASE_DIR)' $(BR2_EXTERNAL))
|
core: offload handling of BR2_EXTERNAL into the script
Currently, we treat the case where we have no br2-external tree
(BR2_EXTERNAL is empty) differently from the case where we do have one
(BR2_EXTERNAL is not empty).
There is now no reason to treat those two cases differently:
- the kconfig snippet is always generated appropriately (i.e. it would
include the br2-external tree if set, or include nothing otherwise);
- we no longer have a dummy br-external tree either.
Also, the Makefile code to handle BR2_EXTERNAL is currently quite
readable if at least a little bit tricky.
However, when we're going to add support for using multiple br2-external
trees simultaneously, this code would need to get much, much more complex.
To keep the Makefile (rather) simple, offload all of the handling of
BR2_EXTERNAL to the recently added br2-external helper script.
However, because of Makefiles idiosyncracies, we can't use a rule to
generate that Makefile fragment.
Instead, we use $(shell ...) to call the helper script, and include the
fragment twice: once before the $(shell ...) so we can grab a previously
defined BR2_EXTERNAL value, a second time to use the one passed on the
command line, if any.
Furthermore, we can't error out (e.g. on non-existent br2-external tree)
directly from the fragment or we'd get that error on subsequent calls,
with no chance to override it even from command line.
Instead, we use a variable in which we store the error, set it to empty
before the second inclusion, so that only the one newly generated, if
any, is taken into account.
Since we know the script will always be called from Makefile context
first, we know validation will occur in Makefile context first. So we
can assume that, if there is an error, it will be detected in Makefile
context. Consequently, if the script is called to generate the kconfig
fragment, validation has already occured, and there should be no error.
So we change the error function to generate Makefile code, so that
errors are caught as explained above.
Lastly, when the value of BR2_EXTERNAL changes, we want to 'forget'
about the previous value of the BR2_EXTERNAL_MK variable, especially in
the case where BR2_EXTERNAL is now set to empty, so that we do not try
to include it later. That's why we first generate empty version of
BR2_EXTERNAL_MK, and then assign it the new value, if any.
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: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:15 +02:00
|
|
|
BR2_EXTERNAL_ERROR =
|
|
|
|
|
include $(BR2_EXTERNAL_FILE)
|
|
|
|
|
ifneq ($(BR2_EXTERNAL_ERROR),)
|
|
|
|
|
$(error $(BR2_EXTERNAL_ERROR))
|
core: introduce the BR2_EXTERNAL variable
This commit introduces the BR2_EXTERNAL environment variable, which
will allow to keep Buildroot customization (board-specific
configuration files or root filesystem overlays, package Config.in and
makefiles, as well as defconfigs) outside of the Buildroot tree.
This commit only introduces the variable itself, and ensures that it
is available within Config.in options. This allows us to use
$BR2_EXTERNAL in a 'source' statement in Config.in.
Following patches extend the usage of BR2_EXTERNAL to other areas
(packages and defconfigs).
In details, this commit:
* Introduces the BR2_EXTERNAL Kconfig option. This option has no
prompt, and is therefore not visible to the user and also not
stored in the .config file. It is automatically set to the value of
the BR2_EXTERNAL environment variable. The only purpose of this
BR2_EXTERNAL Kconfig option is to allow $BR2_EXTERNAL to be
properly expanded when used inside Kconfig source statements.
* Calculates the BR2_EXTERNAL value to use. If passed on the command
line, then this value is taken in priority, and saved to a
.br-external hidden file in the output directory. If not passed on
the command line, then we read the .br-external file from the
output directory. This allows the user to not pass the BR2_EXTERNAL
value at each make invocation. If no BR2_EXTERNAL value is passed,
we define it to support/dummy-external, so that the kconfig code
finds an existing $(BR2_EXTERNAL)/package/Config.in file to
include.
* Passes the BR2_EXTERNAL into the *config environment, so that its
value is found when parsing/evaluating Config.in files and .config
values.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
2013-12-05 20:11:10 +01:00
|
|
|
endif
|
|
|
|
|
|
Makefile: work around a bug in newly released make 4.3
Several users of rolling-release distributions have been reporting on
IRC that Buildroot is broken now that they have switched to the newly
released make 4.3.
It turns out that the constructs we use to generated and include the
internal br2-external related fragments is no longer working with
make-4.3.
Indeed, an upstream bug report [0] seems to imply that it so far was
working by chance. There has been no further feedback, whether this is
really considered a fix for a previous ill-defined behaviour, or an
actual regression...
In the meantime, we add a workaround, suggested in that same bug report,
that fixes the issue for make 4.3, and that should not break on older
make versions either (verified on all relevant versions: from 3.81,
3.82, 4.0, 4.1, and 4.2).
[0] https://savannah.gnu.org/bugs/?57676
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Mircea Gliga <mgliga@bitdefender.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-03-04 14:40:37 +01:00
|
|
|
# Workaround bug in make-4.3: https://savannah.gnu.org/bugs/?57676
|
|
|
|
|
$(BASE_DIR)/.br2-external.mk:;
|
|
|
|
|
|
2015-04-08 02:53:36 +02:00
|
|
|
# To make sure that the environment variable overrides the .config option,
|
2014-02-04 16:18:51 +01:00
|
|
|
# set this before including .config.
|
|
|
|
|
ifneq ($(BR2_DL_DIR),)
|
|
|
|
|
DL_DIR := $(BR2_DL_DIR)
|
|
|
|
|
endif
|
2015-10-15 15:24:39 +02:00
|
|
|
ifneq ($(BR2_CCACHE_DIR),)
|
|
|
|
|
BR_CACHE_DIR := $(BR2_CCACHE_DIR)
|
|
|
|
|
endif
|
2014-02-04 16:18:51 +01:00
|
|
|
|
2013-12-28 18:39:13 +01:00
|
|
|
# Need that early, before we scan packages
|
|
|
|
|
# Avoids doing the $(or...) everytime
|
2014-04-13 22:42:37 +02:00
|
|
|
BR_GRAPH_OUT := $(or $(BR2_GRAPH_OUT),pdf)
|
core: introduce the BR2_EXTERNAL variable
This commit introduces the BR2_EXTERNAL environment variable, which
will allow to keep Buildroot customization (board-specific
configuration files or root filesystem overlays, package Config.in and
makefiles, as well as defconfigs) outside of the Buildroot tree.
This commit only introduces the variable itself, and ensures that it
is available within Config.in options. This allows us to use
$BR2_EXTERNAL in a 'source' statement in Config.in.
Following patches extend the usage of BR2_EXTERNAL to other areas
(packages and defconfigs).
In details, this commit:
* Introduces the BR2_EXTERNAL Kconfig option. This option has no
prompt, and is therefore not visible to the user and also not
stored in the .config file. It is automatically set to the value of
the BR2_EXTERNAL environment variable. The only purpose of this
BR2_EXTERNAL Kconfig option is to allow $BR2_EXTERNAL to be
properly expanded when used inside Kconfig source statements.
* Calculates the BR2_EXTERNAL value to use. If passed on the command
line, then this value is taken in priority, and saved to a
.br-external hidden file in the output directory. If not passed on
the command line, then we read the .br-external file from the
output directory. This allows the user to not pass the BR2_EXTERNAL
value at each make invocation. If no BR2_EXTERNAL value is passed,
we define it to support/dummy-external, so that the kconfig code
finds an existing $(BR2_EXTERNAL)/package/Config.in file to
include.
* Passes the BR2_EXTERNAL into the *config environment, so that its
value is found when parsing/evaluating Config.in files and .config
values.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
2013-12-05 20:11:10 +01:00
|
|
|
|
2014-04-23 10:39:23 +02:00
|
|
|
BUILD_DIR := $(BASE_DIR)/build
|
|
|
|
|
BINARIES_DIR := $(BASE_DIR)/images
|
2018-03-31 11:05:50 +02:00
|
|
|
BASE_TARGET_DIR := $(BASE_DIR)/target
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
PER_PACKAGE_DIR := $(BASE_DIR)/per-package
|
2013-10-02 22:06:40 +02:00
|
|
|
# initial definition so that 'make clean' works for most users, even without
|
|
|
|
|
# .config. HOST_DIR will be overwritten later when .config is included.
|
2014-04-23 10:39:23 +02:00
|
|
|
HOST_DIR := $(BASE_DIR)/host
|
2015-02-05 22:19:56 +01:00
|
|
|
GRAPHS_DIR := $(BASE_DIR)/graphs
|
2014-04-23 10:39:23 +02:00
|
|
|
|
|
|
|
|
LEGAL_INFO_DIR = $(BASE_DIR)/legal-info
|
|
|
|
|
REDIST_SOURCES_DIR_TARGET = $(LEGAL_INFO_DIR)/sources
|
|
|
|
|
REDIST_SOURCES_DIR_HOST = $(LEGAL_INFO_DIR)/host-sources
|
|
|
|
|
LICENSE_FILES_DIR_TARGET = $(LEGAL_INFO_DIR)/licenses
|
|
|
|
|
LICENSE_FILES_DIR_HOST = $(LEGAL_INFO_DIR)/host-licenses
|
|
|
|
|
LEGAL_MANIFEST_CSV_TARGET = $(LEGAL_INFO_DIR)/manifest.csv
|
|
|
|
|
LEGAL_MANIFEST_CSV_HOST = $(LEGAL_INFO_DIR)/host-manifest.csv
|
|
|
|
|
LEGAL_WARNINGS = $(LEGAL_INFO_DIR)/.warnings
|
|
|
|
|
LEGAL_REPORT = $(LEGAL_INFO_DIR)/README
|
|
|
|
|
|
|
|
|
|
BR2_CONFIG = $(CONFIG_DIR)/.config
|
2013-01-13 12:52:20 +01:00
|
|
|
|
2008-03-28 08:31:28 +01:00
|
|
|
# Pull in the user's configuration file
|
|
|
|
|
ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
|
2014-02-04 16:18:52 +01:00
|
|
|
-include $(BR2_CONFIG)
|
2007-09-12 06:34:16 +02:00
|
|
|
endif
|
2003-01-19 08:49:24 +01:00
|
|
|
|
2019-11-05 17:46:41 +01:00
|
|
|
ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),)
|
|
|
|
|
# Disable top-level parallel build if per-package directories is not
|
|
|
|
|
# used. Indeed, per-package directories is necessary to guarantee
|
|
|
|
|
# determinism and reproducibility with top-level parallel build.
|
2018-11-23 15:58:09 +01:00
|
|
|
.NOTPARALLEL:
|
2019-11-05 17:46:41 +01:00
|
|
|
endif
|
2018-11-23 15:58:09 +01:00
|
|
|
|
2016-06-14 17:31:10 +02:00
|
|
|
# timezone and locale may affect build output
|
|
|
|
|
ifeq ($(BR2_REPRODUCIBLE),y)
|
2016-11-23 13:58:57 +01:00
|
|
|
export TZ = UTC
|
|
|
|
|
export LANG = C
|
|
|
|
|
export LC_ALL = C
|
2016-06-14 17:31:10 +02:00
|
|
|
endif
|
|
|
|
|
|
2007-06-28 12:47:05 +02:00
|
|
|
# To put more focus on warnings, be less verbose as default
|
|
|
|
|
# Use 'make V=1' to see the full commands
|
2015-04-07 07:09:09 +02:00
|
|
|
ifeq ("$(origin V)", "command line")
|
|
|
|
|
KBUILD_VERBOSE = $(V)
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
|
|
|
|
ifndef KBUILD_VERBOSE
|
2014-04-23 10:39:23 +02:00
|
|
|
KBUILD_VERBOSE = 0
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(KBUILD_VERBOSE),1)
|
2014-04-23 10:39:23 +02:00
|
|
|
Q =
|
2007-09-22 16:19:22 +02:00
|
|
|
ifndef VERBOSE
|
2014-04-23 10:39:23 +02:00
|
|
|
VERBOSE = 1
|
2007-09-22 16:19:22 +02:00
|
|
|
endif
|
2015-06-23 23:36:06 +02:00
|
|
|
export VERBOSE
|
2007-06-28 12:47:05 +02:00
|
|
|
else
|
2014-04-23 10:39:23 +02:00
|
|
|
Q = @
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
|
|
|
|
|
2009-01-01 22:20:35 +01:00
|
|
|
# kconfig uses CONFIG_SHELL
|
2014-04-23 10:39:23 +02:00
|
|
|
CONFIG_SHELL := $(SHELL)
|
2009-01-01 22:20:35 +01:00
|
|
|
|
2015-10-08 22:03:37 +02:00
|
|
|
export SHELL CONFIG_SHELL Q KBUILD_VERBOSE
|
2007-06-28 12:47:05 +02:00
|
|
|
|
|
|
|
|
ifndef HOSTAR
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTAR := ar
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
|
|
|
|
ifndef HOSTAS
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTAS := as
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
|
|
|
|
ifndef HOSTCC
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCC := gcc
|
2021-10-01 20:08:32 +02:00
|
|
|
HOSTCC := $(shell which $(HOSTCC) || type -p $(HOSTCC) || echo gcc)
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
2021-09-28 21:55:33 +02:00
|
|
|
ifndef HOSTCC_NOCCACHE
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCC_NOCCACHE := $(HOSTCC)
|
2021-09-28 21:55:33 +02:00
|
|
|
endif
|
2007-06-28 12:47:05 +02:00
|
|
|
ifndef HOSTCXX
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCXX := g++
|
2021-10-01 20:08:32 +02:00
|
|
|
HOSTCXX := $(shell which $(HOSTCXX) || type -p $(HOSTCXX) || echo g++)
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
2021-09-28 21:55:33 +02:00
|
|
|
ifndef HOSTCXX_NOCCACHE
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCXX_NOCCACHE := $(HOSTCXX)
|
2021-09-28 21:55:33 +02:00
|
|
|
endif
|
2007-09-28 21:46:58 +02:00
|
|
|
ifndef HOSTCPP
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCPP := cpp
|
2007-09-28 21:46:58 +02:00
|
|
|
endif
|
2007-06-28 12:47:05 +02:00
|
|
|
ifndef HOSTLD
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTLD := ld
|
2007-06-28 12:47:05 +02:00
|
|
|
endif
|
2007-07-15 23:54:11 +02:00
|
|
|
ifndef HOSTLN
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTLN := ln
|
2007-07-15 23:54:11 +02:00
|
|
|
endif
|
2007-09-28 21:46:58 +02:00
|
|
|
ifndef HOSTNM
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTNM := nm
|
2007-09-28 21:46:58 +02:00
|
|
|
endif
|
2013-11-11 17:47:26 +01:00
|
|
|
ifndef HOSTOBJCOPY
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTOBJCOPY := objcopy
|
2013-11-11 17:47:26 +01:00
|
|
|
endif
|
|
|
|
|
ifndef HOSTRANLIB
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTRANLIB := ranlib
|
|
|
|
|
endif
|
2021-10-01 20:08:32 +02:00
|
|
|
HOSTAR := $(shell which $(HOSTAR) || type -p $(HOSTAR) || echo ar)
|
|
|
|
|
HOSTAS := $(shell which $(HOSTAS) || type -p $(HOSTAS) || echo as)
|
|
|
|
|
HOSTCPP := $(shell which $(HOSTCPP) || type -p $(HOSTCPP) || echo cpp)
|
|
|
|
|
HOSTLD := $(shell which $(HOSTLD) || type -p $(HOSTLD) || echo ld)
|
|
|
|
|
HOSTLN := $(shell which $(HOSTLN) || type -p $(HOSTLN) || echo ln)
|
|
|
|
|
HOSTNM := $(shell which $(HOSTNM) || type -p $(HOSTNM) || echo nm)
|
|
|
|
|
HOSTOBJCOPY := $(shell which $(HOSTOBJCOPY) || type -p $(HOSTOBJCOPY) || echo objcopy)
|
|
|
|
|
HOSTRANLIB := $(shell which $(HOSTRANLIB) || type -p $(HOSTRANLIB) || echo ranlib)
|
|
|
|
|
SED := $(shell which sed || type -p sed) -i -e
|
2008-07-06 09:34:41 +02:00
|
|
|
|
2015-04-09 13:28:55 +02:00
|
|
|
export HOSTAR HOSTAS HOSTCC HOSTCXX HOSTLD
|
2010-12-07 21:09:56 +01:00
|
|
|
export HOSTCC_NOCCACHE HOSTCXX_NOCCACHE
|
2007-06-28 12:47:05 +02:00
|
|
|
|
core: fix setting of HOSTARCH
Currently, we set HOSTARCH to the output of `uname -m`. This gives us
the architecture as seen by the running kernel. For example, we would
end up with 'x86_64' for a 64-bit kernel running on an x86_64 processor.
We use that value to determine whether we can run some binary tools,
like our pre-configured external toolchains.
However, one may be running a userland in a different bitness than that
of the running kernel. For example, one may run in a 32-bit chroot, even
though the kernel is running in 64-bit.
Up until recently, this was not an issue because the pre-configured
external toolchains were all requiring an i386 (x86 in Buildroot
parlance).
But since we introduced the latest Linaro toolchains, we now have
toolchains that require a 64-bit userland.
So, when running on a 64-bit kernel, we believe those toolchains are
available, even when the user is running a 32-bit userland. This causes
build failures for our autobuilders, like so:
http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/
with the following symptoms:
>>> toolchain-external undefined Configuring
Cannot execute cross-compiler '/home/test/autobuild/instance-3/output/host/opt/ext-toolchain/bin/aarch64-linux-gnu-gcc'
So, instead of relying on the output of `uname -r`, look for the host
gcc and extract the target it was configured to generate code for.
Fixes:
http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/ (aarch64)
http://autobuild.buildroot.org/results/888/8889aa7d9fb48370e4760a6edbc6d3ae945f02f2/ (arm)
and many more...
Besides fixing those issues, it will also allow us to add the 64-bit
variants of toolchains when they exist, like the upcoming Codescape
MTI and IMG toolchains for MIPS from Imagination Technologies.
[Peter: use HOSTCC_NOCCACHE]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-09 20:00:21 +01:00
|
|
|
# Determine the userland we are running on.
|
|
|
|
|
#
|
|
|
|
|
# Note that, despite its name, we are not interested in the actual
|
|
|
|
|
# architecture name. This is mostly used to determine whether some
|
|
|
|
|
# of the binary tools (e.g. pre-built external toolchains) can run
|
|
|
|
|
# on the current host. So we need to know if the userland we're
|
|
|
|
|
# running on can actually run those toolchains.
|
|
|
|
|
#
|
|
|
|
|
# For example, a 64-bit prebuilt toolchain will not run on a 64-bit
|
|
|
|
|
# kernel if the userland is 32-bit (e.g. in a chroot for example).
|
|
|
|
|
#
|
|
|
|
|
# So, we extract the first part of the tuple the host gcc was
|
|
|
|
|
# configured to generate code for; we assume this is our userland.
|
|
|
|
|
#
|
2016-01-20 22:53:19 +01:00
|
|
|
export HOSTARCH := $(shell LC_ALL=C $(HOSTCC_NOCCACHE) -v 2>&1 | \
|
core: fix setting of HOSTARCH
Currently, we set HOSTARCH to the output of `uname -m`. This gives us
the architecture as seen by the running kernel. For example, we would
end up with 'x86_64' for a 64-bit kernel running on an x86_64 processor.
We use that value to determine whether we can run some binary tools,
like our pre-configured external toolchains.
However, one may be running a userland in a different bitness than that
of the running kernel. For example, one may run in a 32-bit chroot, even
though the kernel is running in 64-bit.
Up until recently, this was not an issue because the pre-configured
external toolchains were all requiring an i386 (x86 in Buildroot
parlance).
But since we introduced the latest Linaro toolchains, we now have
toolchains that require a 64-bit userland.
So, when running on a 64-bit kernel, we believe those toolchains are
available, even when the user is running a 32-bit userland. This causes
build failures for our autobuilders, like so:
http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/
with the following symptoms:
>>> toolchain-external undefined Configuring
Cannot execute cross-compiler '/home/test/autobuild/instance-3/output/host/opt/ext-toolchain/bin/aarch64-linux-gnu-gcc'
So, instead of relying on the output of `uname -r`, look for the host
gcc and extract the target it was configured to generate code for.
Fixes:
http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/ (aarch64)
http://autobuild.buildroot.org/results/888/8889aa7d9fb48370e4760a6edbc6d3ae945f02f2/ (arm)
and many more...
Besides fixing those issues, it will also allow us to add the 64-bit
variants of toolchains when they exist, like the upcoming Codescape
MTI and IMG toolchains for MIPS from Imagination Technologies.
[Peter: use HOSTCC_NOCCACHE]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-09 20:00:21 +01:00
|
|
|
sed -e '/^Target: \([^-]*\).*/!d' \
|
|
|
|
|
-e 's//\1/' \
|
|
|
|
|
-e 's/i.86/x86/' \
|
|
|
|
|
-e 's/sun4u/sparc64/' \
|
|
|
|
|
-e 's/arm.*/arm/' \
|
|
|
|
|
-e 's/sa110/arm/' \
|
|
|
|
|
-e 's/ppc64/powerpc64/' \
|
|
|
|
|
-e 's/ppc/powerpc/' \
|
|
|
|
|
-e 's/macppc/powerpc/' \
|
|
|
|
|
-e 's/sh.*/sh/' )
|
|
|
|
|
|
2018-10-23 11:08:40 +02:00
|
|
|
# When adding a new host gcc version in Config.in,
|
|
|
|
|
# update the HOSTCC_MAX_VERSION variable:
|
2023-11-03 01:06:49 +01:00
|
|
|
HOSTCC_MAX_VERSION := 11
|
2018-10-23 11:08:40 +02:00
|
|
|
|
|
|
|
|
HOSTCC_VERSION := $(shell V=$$($(HOSTCC_NOCCACHE) --version | \
|
|
|
|
|
sed -n -r 's/^.* ([0-9]*)\.([0-9]*)\.([0-9]*)[ ]*.*/\1 \2/p'); \
|
|
|
|
|
[ "$${V%% *}" -le $(HOSTCC_MAX_VERSION) ] || V=$(HOSTCC_MAX_VERSION); \
|
|
|
|
|
printf "%s" "$${V}")
|
2015-12-31 01:34:13 +01:00
|
|
|
|
|
|
|
|
# For gcc >= 5.x, we only need the major version.
|
|
|
|
|
ifneq ($(firstword $(HOSTCC_VERSION)),4)
|
|
|
|
|
HOSTCC_VERSION := $(firstword $(HOSTCC_VERSION))
|
|
|
|
|
endif
|
|
|
|
|
|
core: find a host UTF-8 locale
Some packages really want to use an UTF-8 locale, or they break.
However, there is no guarantee that any given locale is available on a
system. For example,, while most mainstream distros (Debian and
derivatives, Fedora...) do have the generic, language-agnostic C.UTF-8
locale, Gentoo does not provide it.
So, find the first UTF-8 locale available on the system, and take any
that is available. We however do favour using the user-set current
locale, then using the language-agnostic C.UTF-8, and eventually any
random UTF-8 locale.
Note: we only need to enforce LC_ALL, because setting it implies
everything else:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
"""
1. If the LC_ALL environment variable is defined and is not null,
the value of LC_ALL shall be used.
"""
[Peter: use same regexp as in dependencies.sh]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-04 11:29:04 +01:00
|
|
|
ifeq ($(BR2_NEEDS_HOST_UTF8_LOCALE),y)
|
|
|
|
|
# First, we try to use the user's configured locale (as that's the
|
|
|
|
|
# language they'd expect messages to be displayed), then we favour
|
|
|
|
|
# a non language-specific locale like C.UTF-8 if one is available,
|
|
|
|
|
# so we sort with the C locale to get it at the top.
|
|
|
|
|
# This is guaranteed to not be empty, because of the check in
|
|
|
|
|
# support/dependencies/dependencies.sh
|
|
|
|
|
HOST_UTF8_LOCALE := $(shell \
|
|
|
|
|
( echo $${LC_ALL:-$${LC_MESSAGES:-$${LANG}}}; \
|
|
|
|
|
locale -a 2>/dev/null | LC_ALL=C sort \
|
|
|
|
|
) \
|
|
|
|
|
| grep -i -E 'utf-?8$$' \
|
|
|
|
|
| head -n 1)
|
|
|
|
|
HOST_UTF8_LOCALE_ENV := LC_ALL=$(HOST_UTF8_LOCALE)
|
|
|
|
|
endif
|
|
|
|
|
|
2012-06-30 12:29:22 +02:00
|
|
|
# Make sure pkg-config doesn't look outside the buildroot tree
|
2015-01-03 00:58:47 +01:00
|
|
|
HOST_PKG_CONFIG_PATH := $(PKG_CONFIG_PATH)
|
2012-06-30 12:29:22 +02:00
|
|
|
unexport PKG_CONFIG_PATH
|
2012-12-02 12:13:04 +01:00
|
|
|
unexport PKG_CONFIG_SYSROOT_DIR
|
2013-09-11 14:15:15 +02:00
|
|
|
unexport PKG_CONFIG_LIBDIR
|
2012-06-30 12:29:22 +02:00
|
|
|
|
2012-07-02 06:21:14 +02:00
|
|
|
# Having DESTDIR set in the environment confuses the installation
|
|
|
|
|
# steps of some packages.
|
|
|
|
|
unexport DESTDIR
|
|
|
|
|
|
2013-07-11 16:37:33 +02:00
|
|
|
# Causes breakage with packages that needs host-ruby
|
|
|
|
|
unexport RUBYOPT
|
|
|
|
|
|
2022-11-06 15:26:34 +01:00
|
|
|
# Compilation of perl-related packages will fail otherwise
|
|
|
|
|
unexport PERL_MM_OPT
|
|
|
|
|
|
2014-08-15 15:40:34 +02:00
|
|
|
include package/pkg-utils.mk
|
2014-10-03 19:01:52 +02:00
|
|
|
include package/doc-asciidoc.mk
|
2014-08-15 15:40:34 +02:00
|
|
|
|
2007-09-29 15:58:30 +02:00
|
|
|
ifeq ($(BR2_HAVE_DOT_CONFIG),y)
|
2003-01-18 22:52:46 +01:00
|
|
|
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2007-06-19 17:19:27 +02:00
|
|
|
#
|
|
|
|
|
# Hide troublesome environment variables from sub processes
|
|
|
|
|
#
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2007-06-19 17:19:27 +02:00
|
|
|
unexport CROSS_COMPILE
|
|
|
|
|
unexport ARCH
|
2010-12-26 00:29:42 +01:00
|
|
|
unexport CC
|
2016-04-14 16:58:32 +02:00
|
|
|
unexport LD
|
|
|
|
|
unexport AR
|
2010-12-26 00:29:42 +01:00
|
|
|
unexport CXX
|
|
|
|
|
unexport CPP
|
2015-11-17 20:04:04 +01:00
|
|
|
unexport RANLIB
|
2010-12-26 00:29:42 +01:00
|
|
|
unexport CFLAGS
|
|
|
|
|
unexport CXXFLAGS
|
|
|
|
|
unexport GREP_OPTIONS
|
2014-01-26 23:58:02 +01:00
|
|
|
unexport TAR_OPTIONS
|
2011-12-12 10:25:50 +01:00
|
|
|
unexport CONFIG_SITE
|
2012-08-17 13:54:16 +02:00
|
|
|
unexport QMAKESPEC
|
2012-07-10 09:37:22 +02:00
|
|
|
unexport TERMINFO
|
2014-09-24 06:37:13 +02:00
|
|
|
unexport MACHINE
|
2015-07-25 21:07:39 +02:00
|
|
|
unexport O
|
2017-02-14 18:24:32 +01:00
|
|
|
unexport GCC_COLORS
|
2019-02-05 12:03:42 +01:00
|
|
|
unexport PLATFORM
|
|
|
|
|
unexport OS
|
2022-02-23 13:41:08 +01:00
|
|
|
unexport DEVICE_TREE
|
2003-01-17 05:31:36 +01:00
|
|
|
|
2014-04-23 10:39:23 +02:00
|
|
|
GNU_HOST_NAME := $(shell support/gnuconfig/config.guess)
|
2010-04-10 23:17:25 +02:00
|
|
|
|
2015-04-12 18:37:48 +02:00
|
|
|
PACKAGES :=
|
2015-10-22 22:33:56 +02:00
|
|
|
PACKAGES_ALL :=
|
2007-07-23 13:29:38 +02:00
|
|
|
|
2009-09-30 17:39:44 +02:00
|
|
|
# silent mode requested?
|
2015-01-01 21:03:50 +01:00
|
|
|
QUIET := $(if $(findstring s,$(filter-out --%,$(MAKEFLAGS))),-q)
|
2009-09-30 17:39:44 +02:00
|
|
|
|
Remove the "project" feature
The "project" feature was designed to allow to several projects to be
built inside the same Buildroot source tree and allowing the toolchain
and non-configurable packages to be shared between the different
projects on the same architecture. While being interesting in theory,
this feature adds a level of complexity to Buildroot, both from an
user perspective and from a developer perspective, while one of the
main Buildroot strengh is to be simple. Moreover, this feature is only
seldomly used by our users.
From a user-level perspective, this for example allows to remove the
project_build_ARCH directory, which was very confusing. The
autotools-stamps directory is also removed, since these stamps are
back at their normal location.
Description of the changes involved :
* project/, directory removed
* Makefile
- Don't include project/Makefile.in and project/project.mk anymore
- Grab a copy of the contents of project/Makefile.in at the
location it was imported, but remove the definition related to
PROJECT_BUILD_DIR. The TARGET_DIR is now in
$(BUILD_DIR)/target_dir
- Remove the creation/removal of the $(PROJECT_BUILD_DIR) and
$(PROJECT_BUILD_DIR)/autotools-stamps directories
- Don't make world depends on target-host-info. This target was
defined by project/project.mk to customize /etc/issue,
/etc/hostname and create /etc/br-version depending on the
project definitions. We can of course imagine re-adding such a
feature later.
- Replace PROJECT_BUILD_DIR by BUILD_DIR everywhere
- Remove the update, log and lognr.$(PROJECT) target, they were
specific to the project feature.
* package/Makefile.autotools.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR for the location of the
configure cache
- Move the INSTALL_TARGET and HOOK_POST_INSTALL stamps to the same
directory as the other stamps (i.e, in the package directory).
* package/Makefile.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR for the location of the
configure cache
* package/at/at.mk,
package/busybox/busybox.mk,
package/busybox/initramfs.mk,
package/customize/customize.mk,
package/linux-fusion/linux-fusion.mk,
package/ltp-testsuite/ltp-testsuite.mk,
package/nfs-utils/nfs-utils.mk,
target/cpio/cpioroot.mk,
target/cramfs/cramfs.mk,
target/device/Atmel/DataFlashBoot/DataflashBoot.mk,
target/device/Atmel/Makefile.in,
target/device/Atmel/at91bootstrap/at91bootstrap.mk,
target/device/KwikByte/Makefile.in,
target/ext2/ext2root.mk,
target/initramfs/initramfs.mk,
target/iso9660/iso9660.mk,
target/jffs2/jffs2root.mk,
target/linux/Makefile.in,
target/romfs/romfs.mk,
target/squashfs/squashfsroot.mk,
target/tar/tarroot.mk,
target/ubifs/ubifsroot.mk
- Replace PROJECT_BUILD_DIR by BUILD_DIR
* target/device/Config.in
- Do not include project/Config.in anymore
* target/linux/Makefile.in.advanced
- Replace PROJECT_BUILD_DIR by BUILD_DIR
- Store the stamps file in $(STAMP_DIR) instead of
$(PROJECT_BUILD_DIR)/autotools-stamps
* target/u-boot/Makefile.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR
- Remove $(PROJECT) from the U-Boot target binary name
- Remove the insertion in the configuration of the project name as
the hostname
- The u-boot-autoscript target now generates
$(U_BOOT_AUTOSCRIPT).img instead of
$(U_BOOT_AUTOSCRIPT).$(PROJECT)
* toolchain/gcc/gcc-uclibc-3.x.mk
toolchain/gcc/gcc-uclibc-4.x.mk
- Move the stamps files to $(STAMP_DIR)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-09-05 15:49:30 +02:00
|
|
|
# Strip off the annoying quoting
|
2014-04-23 10:39:23 +02:00
|
|
|
ARCH := $(call qstrip,$(BR2_ARCH))
|
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH
The variable 'KERNEL_ARCH' is actually a normalized version of
'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just
as all powerpc variants become 'powerpc'.
It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically
the first place where support for a new architecture is added, and thus is
the entity that defines the normalized name.
However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture
used by the kernel', which need not be exactly the same as 'the normalized
name for a certain arch'. In particular, for cases where a 64-bit
architecture is running a 64-bit kernel but 32-bit userspace. Examples
include:
* aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace
* x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace
In such cases, the 'architecture used by the kernel' needs to refer to the
64-bit name (aarch64, x86_64), whereas all userspace applications need to
refer the, potentially normalized, 32-bit name.
This means that there need to be two different variables:
KERNEL_ARCH: the architecture used by the kernel
NORMALIZED_ARCH: the normalized name for the current userspace architecture
At this moment, both will actually have the same content. But a subsequent
patch will add basic support for situations described above, in which
KERNEL_ARCH may become overwritten to the 64-bit architecture, while
NORMALIZED_ARCH needs to remain the same (32-bit) case.
This commit replaces use of KERNEL_ARCH where actually the userspace arch is
needed. Places that use KERNEL_ARCH in combination with building of kernel
modules are not touched.
There may be cases where a package builds both a kernel module as userspace,
in which case it may need to know about both KERNEL_ARCH and
NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on
a per-need basis.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
|
|
|
NORMALIZED_ARCH := $(call qstrip,$(BR2_NORMALIZED_ARCH))
|
|
|
|
|
KERNEL_ARCH := $(call qstrip,$(BR2_NORMALIZED_ARCH))
|
2010-10-17 23:32:37 +02:00
|
|
|
|
2014-04-23 10:39:23 +02:00
|
|
|
ZCAT := $(call qstrip,$(BR2_ZCAT))
|
|
|
|
|
BZCAT := $(call qstrip,$(BR2_BZCAT))
|
|
|
|
|
XZCAT := $(call qstrip,$(BR2_XZCAT))
|
2017-02-12 21:15:39 +01:00
|
|
|
LZCAT := $(call qstrip,$(BR2_LZCAT))
|
2014-04-23 10:39:23 +02:00
|
|
|
TAR_OPTIONS = $(call qstrip,$(BR2_TAR_OPTIONS)) -xf
|
Remove the "project" feature
The "project" feature was designed to allow to several projects to be
built inside the same Buildroot source tree and allowing the toolchain
and non-configurable packages to be shared between the different
projects on the same architecture. While being interesting in theory,
this feature adds a level of complexity to Buildroot, both from an
user perspective and from a developer perspective, while one of the
main Buildroot strengh is to be simple. Moreover, this feature is only
seldomly used by our users.
From a user-level perspective, this for example allows to remove the
project_build_ARCH directory, which was very confusing. The
autotools-stamps directory is also removed, since these stamps are
back at their normal location.
Description of the changes involved :
* project/, directory removed
* Makefile
- Don't include project/Makefile.in and project/project.mk anymore
- Grab a copy of the contents of project/Makefile.in at the
location it was imported, but remove the definition related to
PROJECT_BUILD_DIR. The TARGET_DIR is now in
$(BUILD_DIR)/target_dir
- Remove the creation/removal of the $(PROJECT_BUILD_DIR) and
$(PROJECT_BUILD_DIR)/autotools-stamps directories
- Don't make world depends on target-host-info. This target was
defined by project/project.mk to customize /etc/issue,
/etc/hostname and create /etc/br-version depending on the
project definitions. We can of course imagine re-adding such a
feature later.
- Replace PROJECT_BUILD_DIR by BUILD_DIR everywhere
- Remove the update, log and lognr.$(PROJECT) target, they were
specific to the project feature.
* package/Makefile.autotools.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR for the location of the
configure cache
- Move the INSTALL_TARGET and HOOK_POST_INSTALL stamps to the same
directory as the other stamps (i.e, in the package directory).
* package/Makefile.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR for the location of the
configure cache
* package/at/at.mk,
package/busybox/busybox.mk,
package/busybox/initramfs.mk,
package/customize/customize.mk,
package/linux-fusion/linux-fusion.mk,
package/ltp-testsuite/ltp-testsuite.mk,
package/nfs-utils/nfs-utils.mk,
target/cpio/cpioroot.mk,
target/cramfs/cramfs.mk,
target/device/Atmel/DataFlashBoot/DataflashBoot.mk,
target/device/Atmel/Makefile.in,
target/device/Atmel/at91bootstrap/at91bootstrap.mk,
target/device/KwikByte/Makefile.in,
target/ext2/ext2root.mk,
target/initramfs/initramfs.mk,
target/iso9660/iso9660.mk,
target/jffs2/jffs2root.mk,
target/linux/Makefile.in,
target/romfs/romfs.mk,
target/squashfs/squashfsroot.mk,
target/tar/tarroot.mk,
target/ubifs/ubifsroot.mk
- Replace PROJECT_BUILD_DIR by BUILD_DIR
* target/device/Config.in
- Do not include project/Config.in anymore
* target/linux/Makefile.in.advanced
- Replace PROJECT_BUILD_DIR by BUILD_DIR
- Store the stamps file in $(STAMP_DIR) instead of
$(PROJECT_BUILD_DIR)/autotools-stamps
* target/u-boot/Makefile.in
- Replace PROJECT_BUILD_DIR by BUILD_DIR
- Remove $(PROJECT) from the U-Boot target binary name
- Remove the insertion in the configuration of the project name as
the hostname
- The u-boot-autoscript target now generates
$(U_BOOT_AUTOSCRIPT).img instead of
$(U_BOOT_AUTOSCRIPT).$(PROJECT)
* toolchain/gcc/gcc-uclibc-3.x.mk
toolchain/gcc/gcc-uclibc-4.x.mk
- Move the stamps files to $(STAMP_DIR)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-09-05 15:49:30 +02:00
|
|
|
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
|
|
|
|
|
HOST_DIR = $(if $(PKG),$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/host,$(call qstrip,$(BR2_HOST_DIR)))
|
|
|
|
|
TARGET_DIR = $(if $(ROOTFS),$(ROOTFS_$(ROOTFS)_TARGET_DIR),$(if $(PKG),$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/target,$(BASE_TARGET_DIR)))
|
|
|
|
|
else
|
2014-04-23 10:39:23 +02:00
|
|
|
HOST_DIR := $(call qstrip,$(BR2_HOST_DIR))
|
2018-12-28 11:43:29 +01:00
|
|
|
TARGET_DIR = $(if $(ROOTFS),$(ROOTFS_$(ROOTFS)_TARGET_DIR),$(BASE_TARGET_DIR))
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
endif
|
2018-12-28 11:43:29 +01:00
|
|
|
|
2017-08-04 18:31:30 +02:00
|
|
|
ifneq ($(HOST_DIR),$(BASE_DIR)/host)
|
|
|
|
|
HOST_DIR_SYMLINK = $(BASE_DIR)/host
|
2020-07-13 03:13:21 +02:00
|
|
|
$(HOST_DIR_SYMLINK): | $(BASE_DIR)
|
2020-02-18 16:00:59 +01:00
|
|
|
ln -snf $(HOST_DIR) $(HOST_DIR_SYMLINK)
|
2017-08-04 18:31:30 +02:00
|
|
|
endif
|
|
|
|
|
|
Makefile: don't recreate staging symlink if it exists
Create the staging symlink the same way as the host symlink. This means
using a make dependency rather than recreating it every time.
In coreutils versions below 8.27, re-creation of symbolic links was not
atomic. This means that there is a period in time where the existing link is
removed, before the new one is created. In coreutils 8.27 this was fixed,
see [1]. Note that CentOS 7 ships with coreutils 8.22.
In the following scenario, this is a problem:
- an application is compiled using the sysroot prepared by Buildroot and
links against Xenomai userspace libraries, but its build process is steered
from outside of Buildroot
- to know the correct flags, the application makefile uses the 'xeno-config'
file to request them, and passes DESTDIR=/buildroot/output/staging
- the xeno-config responds with flags based on the path
'/buildroot/output/staging/...'
- while the application build is ongoing, a 'make' happens in Buildroot,
causing the 'staging' symlink to be recreated (even though it already
existed)
- when exactly at this time, the application calls the compiler with -I
flags pointing to output/staging, the build fails with:
-I/buildroot/output/staging/usr/include/xenomai/mercury: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/psos: Error: ^ is not a directory
Failed: ** ^ *
Work around this problem by only creating the staging symlink once, similar
to how the host symlink (if any) is created.
See also commit d0f4f95e390bcb1c953efa125f5277a8a235396e which changed the
way these symlinks are made. The reasoning in this commit is to move away
from the 'dirs' target.
[1] https://github.com/coreutils/coreutils/commit/376967889ed7ed561e46ff6d88a66779db62737a
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-18 16:01:00 +01:00
|
|
|
STAGING_DIR_SYMLINK = $(BASE_DIR)/staging
|
2020-07-13 03:13:21 +02:00
|
|
|
$(STAGING_DIR_SYMLINK): | $(BASE_DIR)
|
Makefile: don't recreate staging symlink if it exists
Create the staging symlink the same way as the host symlink. This means
using a make dependency rather than recreating it every time.
In coreutils versions below 8.27, re-creation of symbolic links was not
atomic. This means that there is a period in time where the existing link is
removed, before the new one is created. In coreutils 8.27 this was fixed,
see [1]. Note that CentOS 7 ships with coreutils 8.22.
In the following scenario, this is a problem:
- an application is compiled using the sysroot prepared by Buildroot and
links against Xenomai userspace libraries, but its build process is steered
from outside of Buildroot
- to know the correct flags, the application makefile uses the 'xeno-config'
file to request them, and passes DESTDIR=/buildroot/output/staging
- the xeno-config responds with flags based on the path
'/buildroot/output/staging/...'
- while the application build is ongoing, a 'make' happens in Buildroot,
causing the 'staging' symlink to be recreated (even though it already
existed)
- when exactly at this time, the application calls the compiler with -I
flags pointing to output/staging, the build fails with:
-I/buildroot/output/staging/usr/include/xenomai/mercury: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/psos: Error: ^ is not a directory
Failed: ** ^ *
Work around this problem by only creating the staging symlink once, similar
to how the host symlink (if any) is created.
See also commit d0f4f95e390bcb1c953efa125f5277a8a235396e which changed the
way these symlinks are made. The reasoning in this commit is to move away
from the 'dirs' target.
[1] https://github.com/coreutils/coreutils/commit/376967889ed7ed561e46ff6d88a66779db62737a
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-18 16:01:00 +01:00
|
|
|
ln -snf $(STAGING_DIR) $(STAGING_DIR_SYMLINK)
|
|
|
|
|
|
2014-04-15 00:31:04 +02:00
|
|
|
# Quotes are needed for spaces and all in the original PATH content.
|
2017-07-04 16:03:55 +02:00
|
|
|
BR_PATH = "$(HOST_DIR)/bin:$(HOST_DIR)/sbin:$(PATH)"
|
2014-04-15 00:31:04 +02:00
|
|
|
|
2012-11-17 04:52:14 +01:00
|
|
|
# Location of a file giving a big fat warning that output/target
|
|
|
|
|
# should not be used as the root filesystem.
|
Makefile: define TARGET_DIR_WARNING_FILE relative to TARGET_DIR
In commit 7e9870ce32d6329d9e3d602247fbe1709a2275a4 ("core: introduce
intermediate BASE_TARGET_DIR variable"), the definition of
TARGET_DIR_WARNING_FILE was changed to use $(BASE_TARGET_DIR) instead
of $(TARGET_DIR).
However, this change is incompatible with per-package directories, and
is in fact not needed.
With per-package directories, using $(BASE_TARGET_DIR) means that
TARGET_DIR_WARNING_FILE is
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM. Due to this, when
skeleton-init-common or skeleton-custom attempt to install it, it
fails, because it should be installed to their package per-package
target directory, and not the global output/target directory that doesn't
exist yet. The failure looks like this:
/usr/bin/install -m 0644 support/misc/target-dir-warning.txt /home/thomas/projets/buildroot/output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
/usr/bin/install: cannot create regular file '/home/thomas/projets/buildroot/output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM': No such file or directory
make[1]: *** [package/pkg-generic.mk:336: /home/thomas/projets/buildroot/output/build/skeleton-init-common/.stamp_target_installed] Error 1
TARGET_DIR_WARNING_FILE is used in three places:
- In skeleton-custom.mk and skeleton-init-common.mk, where as
explained above, using $(TARGET_DIR) fixes the use of
$(TARGET_DIR_WARNING_FILE) in the context of per-package target
directories.
- In fs/common.mk, where it is used as argument to $(notdir ...) to
retrieve just the name of the warning file. So in this case, we
really don't care about the path of the file, just its name.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-23 15:58:10 +01:00
|
|
|
TARGET_DIR_WARNING_FILE = $(TARGET_DIR)/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
|
2012-11-17 04:52:14 +01:00
|
|
|
|
2010-12-07 21:09:56 +01:00
|
|
|
ifeq ($(BR2_CCACHE),y)
|
2018-11-23 15:58:06 +01:00
|
|
|
CCACHE = $(HOST_DIR)/bin/ccache
|
2015-10-15 15:24:39 +02:00
|
|
|
BR_CACHE_DIR ?= $(call qstrip,$(BR2_CCACHE_DIR))
|
2014-02-04 16:18:50 +01:00
|
|
|
export BR_CACHE_DIR
|
2018-11-23 15:58:06 +01:00
|
|
|
HOSTCC = $(CCACHE) $(HOSTCC_NOCCACHE)
|
|
|
|
|
HOSTCXX = $(CCACHE) $(HOSTCXX_NOCCACHE)
|
Makefile, toolchain-wrapper.c: disable ccache by default outside of Buildroot
Until now, when BR2_CCACHE=y, ccache support was built into the
toolchain wrapper, and used regardless of whether the toolchain is
using during the Buildroot build itself, or later as part of the SDK.
However, having ccache support forcefully enabled in the SDK can
really be surprising, and is certainly unexpected for a
cross-compilation toolchain. This can be particularly surprising as
the ccache cache directory may be hardcoded in the ccache binary to
point to a folder that does not make sense on the SDK user's machine.
So what this commit does is create a BR2_USE_CCACHE variable, which
when set to 1 tells the toolchain wrapper to use ccache. Not defining
the variable, or specifying any other value that 1 causes the
toolchain wrapper to not use ccache. The main Buildroot Makefile is
modified to export BR2_USE_CCACHE = 1 when ccache support is enabled,
so that ccache is used during the Buildroot build.
However, when someone will use the SDK outside of Buildroot, the
toolchain wrapper will not use ccache.
The BR2_USE_CCACHE variable is only conditionally enabled in the main
Makefile (via ?=) so that it can be overridden in the environment if
one wants to quickly test disabling ccache in a ccache-enabled
Buildroot configuration. This is the scenario that was considered in
commit 792f1278e3fbc165086aebb8c07cfd18e10f374b ("toolchain-wrapper:
support change of BR2_CCACHE"), which added the BR_NO_CCACHE variable.
The BR_NO_CCACHE variable is no longer needed, and replaced by this
BR2_USE_CCACHE variable.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
[Thomas: almost entirely rework the implementation and commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-01-13 22:04:31 +01:00
|
|
|
export BR2_USE_CCACHE ?= 1
|
2010-12-07 21:09:56 +01:00
|
|
|
endif
|
|
|
|
|
|
2013-01-13 12:52:20 +01:00
|
|
|
# Scripts in support/ or post-build scripts may need to reference
|
|
|
|
|
# these locations, so export them so it is easier to use
|
2014-02-04 16:18:52 +01:00
|
|
|
export BR2_CONFIG
|
2016-06-14 17:31:10 +02:00
|
|
|
export BR2_REPRODUCIBLE
|
2013-01-13 12:52:20 +01:00
|
|
|
export TARGET_DIR
|
|
|
|
|
export STAGING_DIR
|
|
|
|
|
export HOST_DIR
|
|
|
|
|
export BINARIES_DIR
|
2013-01-14 10:02:29 +01:00
|
|
|
export BASE_DIR
|
2013-01-13 12:52:20 +01:00
|
|
|
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2007-06-02 11:05:40 +02:00
|
|
|
#
|
|
|
|
|
# You should probably leave this stuff alone unless you know
|
|
|
|
|
# what you are doing.
|
|
|
|
|
#
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2007-06-02 11:05:40 +02:00
|
|
|
|
2007-08-22 14:35:41 +02:00
|
|
|
all: world
|
2001-12-22 01:56:11 +01:00
|
|
|
|
2012-11-12 11:08:28 +01:00
|
|
|
# Include legacy before the other things, because package .mk files
|
|
|
|
|
# may rely on it.
|
|
|
|
|
include Makefile.legacy
|
|
|
|
|
|
2017-07-18 19:25:31 +02:00
|
|
|
include system/system.mk
|
2012-04-17 16:45:23 +02:00
|
|
|
include package/Makefile.in
|
2018-09-12 12:22:53 +02:00
|
|
|
# arch/arch.mk must be after package/Makefile.in because it may need to
|
2017-03-14 19:30:30 +01:00
|
|
|
# complement variables defined therein, like BR_NO_CHECK_HASH_FOR.
|
2018-09-12 12:22:53 +02:00
|
|
|
include arch/arch.mk
|
2012-02-08 17:22:16 +01:00
|
|
|
include support/dependencies/dependencies.mk
|
|
|
|
|
|
2017-11-21 20:13:30 +01:00
|
|
|
include $(sort $(wildcard toolchain/*.mk))
|
|
|
|
|
include $(sort $(wildcard toolchain/*/*.mk))
|
2007-07-23 13:29:38 +02:00
|
|
|
|
2018-04-09 18:08:01 +02:00
|
|
|
ifeq ($(BR2_REPRODUCIBLE),y)
|
|
|
|
|
# If SOURCE_DATE_EPOCH has not been set then use the commit date, or the last
|
|
|
|
|
# release date if the source tree is not within a Git repository.
|
|
|
|
|
# See: https://reproducible-builds.org/specs/source-date-epoch/
|
2018-04-10 12:28:12 +02:00
|
|
|
BR2_VERSION_GIT_EPOCH := $(shell $(GIT) log -1 --format=%at 2> /dev/null)
|
2018-04-09 18:08:01 +02:00
|
|
|
export SOURCE_DATE_EPOCH ?= $(or $(BR2_VERSION_GIT_EPOCH),$(BR2_VERSION_EPOCH))
|
|
|
|
|
endif
|
|
|
|
|
|
2011-09-29 21:57:38 +02:00
|
|
|
# Include the package override file if one has been provided in the
|
|
|
|
|
# configuration.
|
2014-04-23 10:39:23 +02:00
|
|
|
PACKAGE_OVERRIDE_FILE = $(call qstrip,$(BR2_PACKAGE_OVERRIDE_FILE))
|
2011-09-29 21:57:38 +02:00
|
|
|
ifneq ($(PACKAGE_OVERRIDE_FILE),)
|
|
|
|
|
-include $(PACKAGE_OVERRIDE_FILE)
|
|
|
|
|
endif
|
|
|
|
|
|
2013-09-03 10:45:41 +02:00
|
|
|
include $(sort $(wildcard package/*/*.mk))
|
2005-02-10 04:06:39 +01:00
|
|
|
|
2010-11-07 19:33:11 +01:00
|
|
|
include boot/common.mk
|
|
|
|
|
include linux/linux.mk
|
2014-05-05 09:52:13 +02:00
|
|
|
include fs/common.mk
|
2010-11-07 19:33:11 +01:00
|
|
|
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
# If using a br2-external tree, the BR2_EXTERNAL_$(NAME)_PATH variables
|
|
|
|
|
# are also present in the .config file. Since .config is included after
|
|
|
|
|
# we defined them in the Makefile, the values for those variables are
|
|
|
|
|
# quoted. We just include the generated Makefile fragment .br2-external.mk
|
|
|
|
|
# a third time, which will set those variables to the un-quoted values.
|
core: introduce per br2-external NAME
This unique NAME is used to construct a per br2-external tree variable,
BR2_EXTERNAL_$(NAME)_PATH, which contains the path to the br2-external
tree.
This variable is available both from Kconfig (set in the Kconfig
snippet) and from the .mk files.
Also, display the NAME and its path as a comment in the menuconfig.
This will ultimately allow us to support multiple br2-external trees at
once, with that NAME (and thus BR2_EXTERNAL_$(NAME)) uniquely defining
which br2-external tree is being used.
The obvious outcome is that BR2_EXTERNAL should now no longer be used to
refer to the files in the br2-external tree; that location is now known
from the BR2_EXTERNAL_$(NAME)_PATH variable instead. This means we no
longer need to expose, and must stop from from exposing BR2_EXTERNAL as
a Kconfig variable.
Finally, this also fixes a latent bug in the pkg-generic infra, where we
would so far always refer to BR2_EXTERNAL (even if not set) to filter
the names of packages (to decide whether they are a bootloader, a
toolchain or a simple package).
Note: since the variables in the Makefile and in Kconfig are named the
same, the one we computed early on in the Makefile will be overridden by
the one in .config when we have it. Thus, even though they are set to
the same raw value, the one from .config is quoted and, being included
later in the Makefile, will take precedence, so we just re-include the
generated Makefile fragment a third time before includeing the
br2-external's Makefiles. That's unfortunate, but there is no easy way
around that as we do want the two variables to be named the same in
Makefile and Kconfig (and we can't ask the user to un-quote that variable
himself either), hence this little dirty triple-inclusion trick.
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: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:17 +02:00
|
|
|
include $(BR2_EXTERNAL_FILE)
|
|
|
|
|
|
2016-10-14 16:39:14 +02:00
|
|
|
# Nothing to include if no BR2_EXTERNAL tree in use
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
include $(BR2_EXTERNAL_MKS)
|
2013-12-05 20:11:11 +01:00
|
|
|
|
pkg-generic: improve incorrectly used package detection
Currently, the check that packages we build are indeed enabled is done
at the time a package is configured.
This can come quite late in the build process, and does not provide
direct knowledge of the real culprit for the incorrect dependency.
However, we can improve these two issues quite easily, albeit at the
expense of a very slightly more complicated make code.
First, the check can not be done at the time we define the package, i.e.
in the inner-generic-pacakge, because all its dependencies might have
not been parsed yet, so we can't yet know whether it is enabled or not
(because we can't match the package name of the dependency to its
Kconfig variable yet).
But then, we know we have all packages definitions after we scanned the
the bundled packages, kernel, bootloaders and toolchains, as well as the
br2-external tree (if any).
So, at this location, we iterate through the list of enabled packages,
and check that the packages they each depend on are indeed enabled.
This allows us to:
1- do the check very early, before any build action,
2- report on the exact offending package very easily.
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>
2016-01-01 01:01:23 +01:00
|
|
|
# Now we are sure we have all the packages scanned and defined. We now
|
|
|
|
|
# check for each package in the list of enabled packages, that all its
|
|
|
|
|
# dependencies are indeed enabled.
|
|
|
|
|
#
|
|
|
|
|
# Only trigger the check for default builds. If the user forces building
|
|
|
|
|
# a package, even if not enabled in the configuration, we want to accept
|
2019-01-02 16:49:20 +01:00
|
|
|
# it. However; we also want to be able to force checking the dependencies
|
|
|
|
|
# if the user so desires. Forcing a dependency check is useful in the case
|
|
|
|
|
# of test-pkg, as we want to make sure during testing, that a package has
|
|
|
|
|
# all the dependencies selected in the config file.
|
pkg-generic: improve incorrectly used package detection
Currently, the check that packages we build are indeed enabled is done
at the time a package is configured.
This can come quite late in the build process, and does not provide
direct knowledge of the real culprit for the incorrect dependency.
However, we can improve these two issues quite easily, albeit at the
expense of a very slightly more complicated make code.
First, the check can not be done at the time we define the package, i.e.
in the inner-generic-pacakge, because all its dependencies might have
not been parsed yet, so we can't yet know whether it is enabled or not
(because we can't match the package name of the dependency to its
Kconfig variable yet).
But then, we know we have all packages definitions after we scanned the
the bundled packages, kernel, bootloaders and toolchains, as well as the
br2-external tree (if any).
So, at this location, we iterate through the list of enabled packages,
and check that the packages they each depend on are indeed enabled.
This allows us to:
1- do the check very early, before any build action,
2- report on the exact offending package very easily.
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>
2016-01-01 01:01:23 +01:00
|
|
|
#
|
|
|
|
|
ifeq ($(MAKECMDGOALS),)
|
2019-01-02 16:49:20 +01:00
|
|
|
BR_FORCE_CHECK_DEPENDENCIES = YES
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR_FORCE_CHECK_DEPENDENCIES),YES)
|
pkg-generic: improve incorrectly used package detection
Currently, the check that packages we build are indeed enabled is done
at the time a package is configured.
This can come quite late in the build process, and does not provide
direct knowledge of the real culprit for the incorrect dependency.
However, we can improve these two issues quite easily, albeit at the
expense of a very slightly more complicated make code.
First, the check can not be done at the time we define the package, i.e.
in the inner-generic-pacakge, because all its dependencies might have
not been parsed yet, so we can't yet know whether it is enabled or not
(because we can't match the package name of the dependency to its
Kconfig variable yet).
But then, we know we have all packages definitions after we scanned the
the bundled packages, kernel, bootloaders and toolchains, as well as the
br2-external tree (if any).
So, at this location, we iterate through the list of enabled packages,
and check that the packages they each depend on are indeed enabled.
This allows us to:
1- do the check very early, before any build action,
2- report on the exact offending package very easily.
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>
2016-01-01 01:01:23 +01:00
|
|
|
|
|
|
|
|
define CHECK_ONE_DEPENDENCY
|
|
|
|
|
ifeq ($$($(2)_TYPE),target)
|
|
|
|
|
ifneq ($$($$($(2)_KCONFIG_VAR)),y)
|
|
|
|
|
$$(error $$($(2)_NAME) is in the dependency chain of $$($(1)_NAME) that \
|
|
|
|
|
has added it to its _DEPENDENCIES variable without selecting it or \
|
|
|
|
|
depending on it from Config.in)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(foreach pkg,$(call UPPERCASE,$(PACKAGES)),\
|
|
|
|
|
$(foreach dep,$(call UPPERCASE,$($(pkg)_FINAL_ALL_DEPENDENCIES)),\
|
|
|
|
|
$(eval $(call CHECK_ONE_DEPENDENCY,$(pkg),$(dep))$(sep))))
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2014-02-04 16:18:52 +01:00
|
|
|
$(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
|
2018-09-19 13:36:15 +02:00
|
|
|
$(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" syncconfig
|
Ensure that all config-related files are generated before the build
The previous commit has removed calls to conf_write_autoconf(), which
is the function that generates the KCONFIG_AUTOCONF,
KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
one file per config item). Therefore, those things were not generated
anymore before the build.
In order to get them generated before the build, we use the same
mechanism as the kernel: run a silentoldconfig when the .config file
is newer than the KCONFIG_AUTOCONF file.
In Buildroot, all those elements are not really used today, except the
split config which is used a little bit in the toolchain build, in a
try to make sure the toolchain gets rebuilt properly when the
configuration changes. It does not seem that this work has been
completed.
However, as we want to keep the same behaviour as previously, we have
to generate all those elements before starting the build.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-22 07:27:09 +02:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: prepare
|
Ensure that all config-related files are generated before the build
The previous commit has removed calls to conf_write_autoconf(), which
is the function that generates the KCONFIG_AUTOCONF,
KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
one file per config item). Therefore, those things were not generated
anymore before the build.
In order to get them generated before the build, we use the same
mechanism as the kernel: run a silentoldconfig when the .config file
is newer than the KCONFIG_AUTOCONF file.
In Buildroot, all those elements are not really used today, except the
split config which is used a little bit in the toolchain build, in a
try to make sure the toolchain gets rebuilt properly when the
configuration changes. It does not seem that this work has been
completed.
However, as we want to keep the same behaviour as previously, we have
to generate all those elements before starting the build.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-22 07:27:09 +02:00
|
|
|
prepare: $(BUILD_DIR)/buildroot-config/auto.conf
|
2020-01-22 00:09:56 +01:00
|
|
|
@$(foreach s, $(call qstrip,$(BR2_ROOTFS_PRE_BUILD_SCRIPT)), \
|
|
|
|
|
$(call MESSAGE,"Executing pre-build script $(s)"); \
|
|
|
|
|
$(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
|
Ensure that all config-related files are generated before the build
The previous commit has removed calls to conf_write_autoconf(), which
is the function that generates the KCONFIG_AUTOCONF,
KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
one file per config item). Therefore, those things were not generated
anymore before the build.
In order to get them generated before the build, we use the same
mechanism as the kernel: run a silentoldconfig when the .config file
is newer than the KCONFIG_AUTOCONF file.
In Buildroot, all those elements are not really used today, except the
split config which is used a little bit in the toolchain build, in a
try to make sure the toolchain gets rebuilt properly when the
configuration changes. It does not seem that this work has been
completed.
However, as we want to keep the same behaviour as previously, we have
to generate all those elements before starting the build.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-22 07:27:09 +02:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: world
|
2014-02-14 10:55:06 +01:00
|
|
|
world: target-post-image
|
2013-01-14 23:02:00 +01:00
|
|
|
|
core/sdk: generate the SDK tarball ourselves
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>
2018-08-04 10:27:41 +02:00
|
|
|
.PHONY: prepare-sdk
|
|
|
|
|
prepare-sdk: world
|
2017-07-22 13:15:40 +02:00
|
|
|
@$(call MESSAGE,"Rendering the SDK relocatable")
|
2022-10-20 13:55:12 +02:00
|
|
|
PARALLEL_JOBS=$(PARALLEL_JOBS) \
|
|
|
|
|
PER_PACKAGE_DIR=$(PER_PACKAGE_DIR) \
|
|
|
|
|
$(TOPDIR)/support/scripts/fix-rpath host
|
|
|
|
|
PARALLEL_JOBS=$(PARALLEL_JOBS) \
|
|
|
|
|
PER_PACKAGE_DIR=$(PER_PACKAGE_DIR) \
|
|
|
|
|
$(TOPDIR)/support/scripts/fix-rpath staging
|
2022-12-27 16:43:00 +01:00
|
|
|
$(call ppd-fixup-paths,$(BASE_DIR))
|
2017-07-22 13:15:40 +02:00
|
|
|
$(INSTALL) -m 755 $(TOPDIR)/support/misc/relocate-sdk.sh $(HOST_DIR)/relocate-sdk.sh
|
2018-03-26 09:23:32 +02:00
|
|
|
mkdir -p $(HOST_DIR)/share/buildroot
|
2017-07-22 13:15:40 +02:00
|
|
|
echo $(HOST_DIR) > $(HOST_DIR)/share/buildroot/sdk-location
|
|
|
|
|
|
core/sdk: generate the SDK tarball ourselves
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>
2018-08-04 10:27:41 +02:00
|
|
|
BR2_SDK_PREFIX ?= $(GNU_TARGET_NAME)_sdk-buildroot
|
|
|
|
|
.PHONY: sdk
|
|
|
|
|
sdk: prepare-sdk $(BR2_TAR_HOST_DEPENDENCY)
|
|
|
|
|
@$(call MESSAGE,"Generating SDK tarball")
|
|
|
|
|
$(if $(BR2_SDK_PREFIX),,$(error BR2_SDK_PREFIX can not be empty))
|
|
|
|
|
$(Q)mkdir -p $(BINARIES_DIR)
|
|
|
|
|
$(TAR) czf "$(BINARIES_DIR)/$(BR2_SDK_PREFIX).tar.gz" \
|
|
|
|
|
--owner=0 --group=0 --numeric-owner \
|
core/sdk: don't mangle symlinks with '.' or '..' at start
The current transform changes any '.' at the start of a filename to
$(BR2_SDK_PREFIX). This also applies to the target of a symlink, when
it is relative.
We thus might end up with something like:
$(BR2_SDK_PREFIX)/bin/aarch64-linux-gnu-ar ->
$(BR2_SDK_PREFIX)./opt/ext-toolchain/bin/aarch64-linux-gnu-ar
when it should be:
$(BR2_SDK_PREFIX)/bin/aarch64-linux-gnu-ar ->
../opt/ext-toolchain/bin/aarch64-linux-gnu-ar
We fix that by making sure we always remove a known prefix, i.e. we
remove the path to host dir. The obvious solution would be to cd into
$(HOST_DIR)/.. , then tar ./host/ and finally use a --transfrom pattern
as 's,^\./$(notdir $(HOST_DIR)),$(BR2_SDK_PREFIX)'.
Since $(HOST_DIR) can point to a user-supplied location, we don't know
very well how the pattern may patch.
Instead, we cd into / and tar the full path to $(HOST_DIR).
Since tar removes any leading '/', it would spurr a warning message,
which is annoying. So we explicitly remove the leading '/' from
$(HOST_DIR) when we tar it.
Finally, we transform all filenames to replace a leading $(HOST_DIR)
(without a leading /) to the prefix to use.
Signed-off-by: Joel Carlson <JoelsonCarl@gmail.com>
[yann.morin.1998@free.fr:
- use a single transform pattern
- use full HOST_DIR path as pattern to replace
- update commit log accordingly
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2018-12-22 16:18:52 +01:00
|
|
|
--transform='s#^$(patsubst /%,%,$(HOST_DIR))#$(BR2_SDK_PREFIX)#' \
|
|
|
|
|
-C / $(patsubst /%,%,$(HOST_DIR))
|
core/sdk: generate the SDK tarball ourselves
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>
2018-08-04 10:27:41 +02:00
|
|
|
|
infra: centralize rsync exclude list for VCS files
Buildroot has three places where rsync is used:
1. to copy the target skeleton
2. to copy the rootfs overlay(s)
3. to copy overridden package sources
In all of these cases, we want to exclude version control files by default.
Place 1 and 2 used an identical set of explicit --exclude options, while
place 3 used the option --cvs-exclude. This last option, however, not only
excludes version control files, but also binary files (.o, .so) and any file
or directory named 'core' (a problem for the linux kernel that has several
directories with this name). Moreover, the exact list of excluded files when
using --cvs-exclude depends on the version of rsync.
This patch creates one global variable RSYNC_VCS_EXCLUSIONS that can be used
by the various rsync commands. It excludes the version control files of
svn, git, hg, cvs and bzr.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-11-07 11:41:22 +01:00
|
|
|
RSYNC_VCS_EXCLUSIONS = \
|
|
|
|
|
--exclude .svn --exclude .git --exclude .hg --exclude .bzr \
|
|
|
|
|
--exclude CVS
|
|
|
|
|
|
2018-07-03 12:06:14 +02:00
|
|
|
# When stripping, obey to BR2_STRIP_EXCLUDE_DIRS and
|
|
|
|
|
# BR2_STRIP_EXCLUDE_FILES
|
|
|
|
|
STRIP_FIND_COMMON_CMD = \
|
|
|
|
|
find $(TARGET_DIR) \
|
|
|
|
|
$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS)), \
|
|
|
|
|
\( $(call finddirclauses,$(TARGET_DIR),$(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS))) \) \
|
|
|
|
|
-prune -o \
|
|
|
|
|
) \
|
|
|
|
|
$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES)), \
|
|
|
|
|
-not \( $(call findfileclauses,$(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) )
|
|
|
|
|
|
|
|
|
|
# Regular stripping for everything, except libpthread, ld-*.so and
|
|
|
|
|
# kernel modules:
|
2014-04-30 21:29:02 +02:00
|
|
|
# - libpthread.so: a non-stripped libpthread shared library is needed for
|
|
|
|
|
# proper debugging of pthread programs using gdb.
|
2015-10-06 21:51:36 +02:00
|
|
|
# - ld.so: a non-stripped dynamic linker library is needed for valgrind
|
2014-04-30 21:29:02 +02:00
|
|
|
# - kernel modules (*.ko): do not function properly when stripped like normal
|
|
|
|
|
# applications and libraries. Normally kernel modules are already excluded
|
2018-07-03 12:06:14 +02:00
|
|
|
# by the executable permission check, so the explicit exclusion is only
|
2014-04-30 21:29:02 +02:00
|
|
|
# done for kernel modules with incorrect permissions.
|
2018-07-03 12:06:14 +02:00
|
|
|
STRIP_FIND_CMD = \
|
|
|
|
|
$(STRIP_FIND_COMMON_CMD) \
|
|
|
|
|
-type f \( -perm /111 -o -name '*.so*' \) \
|
|
|
|
|
-not \( $(call findfileclauses,libpthread*.so* ld-*.so* *.ko) \) \
|
|
|
|
|
-print0
|
|
|
|
|
|
|
|
|
|
# Special stripping (only debugging symbols) for libpthread and ld-*.so.
|
|
|
|
|
STRIP_FIND_SPECIAL_LIBS_CMD = \
|
|
|
|
|
$(STRIP_FIND_COMMON_CMD) \
|
|
|
|
|
\( -name 'ld-*.so*' -o -name 'libpthread*.so*' \) \
|
|
|
|
|
-print0
|
2012-06-21 21:34:50 +02:00
|
|
|
|
Makefile: Parallelize glibc locale generation
Parallelizes locale generation based on `BR2_JLEVEL` setting.
Locale generation always runs during the finalize stage and can consume
a significant amount of time. Parallelizing it greatly reduces that time
on multi-core machines.
To parallelize it, we first invoke `localedef` for every locale in
parallel with the `--no-archive` option. This creates the intermediate
locale data instead of writing to the finally archive directly.
Then, we invoke `localedef` again once to create the archive from the
intermediate compiled locale data files.
We have to do it this way because `localedef` does not do any locking
when writing to the archive file, so calling it without `--no-archive`
concurrently could result in a corrupt archive file or an archive file
that is missing some locales.
While we're at it, make two additional improvements:
- Remove locale-archive before adding to it. Otherwise, repeated
applications of target-finalize will keep on growing the file.
- Sort the locales when creating locale-archive so its contents are
reproducible.
We use `find` to collect the installed locales rather than LOCALES. This
makes it possible for something else (skeleton, overlay, custom package)
to create and install additional locales and still have them added to
locale-archive.
Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com>
[Arnout:
- Remove -j$(PARALLEL_JOBS), it's already part of $(MAKE)
- Remove HOST_DIR, TARGET_DIR, STAGING_DIR, they're already exported
- Extend commit message
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-01-03 18:15:25 +01:00
|
|
|
# Generate locale data.
|
2014-06-27 14:15:58 +02:00
|
|
|
ifeq ($(BR2_TOOLCHAIN_USES_GLIBC),y)
|
2014-11-13 23:17:23 +01:00
|
|
|
GLIBC_GENERATE_LOCALES = $(call qstrip,$(BR2_GENERATE_LOCALE))
|
|
|
|
|
ifneq ($(GLIBC_GENERATE_LOCALES),)
|
2015-04-12 18:37:48 +02:00
|
|
|
PACKAGES += host-localedef
|
2014-06-27 14:15:58 +02:00
|
|
|
|
2014-11-13 23:17:23 +01:00
|
|
|
define GENERATE_GLIBC_LOCALES
|
Makefile: really generate glibc locales in parallel
To generate the glibc locale data, we call into a recursive Makefile,
so as to generate locales in parallel. This is done as part of a
target-finalize hook.
However, that hook is registered after all packages have been parsed,
and as such, it maye be registered after hooks defined in packages.
Furthermore, the expansion of target-finalize hooks is done in a recipe,
so it is not easy to understand whether this generates a "simple" rule
or not.
As a consequence, despite the use of $(MAKE), make may not notice that
the command is a recursive call, and will decide to close the jobserver
file-descriptors, yielding warnings like:
make[2]: warning: jobserver unavailable: using -j1. Add '+' to
parent make rule.
This causes the lcoale data to not be generated in parallel, which is
initially all the fuss about using a sub-makefile...
So, do as suggested, and prepend the hook with a '+', so that it is
explicit to make that it should not close its jobserver fds.
Fixes: 6fbdf5159607 (Makefile: Parallelize glibc locale generation)
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Gleb Mazovetskiy <glex.spb@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-14 13:18:25 +02:00
|
|
|
+$(MAKE) -f support/misc/gen-glibc-locales.mk \
|
Makefile: Parallelize glibc locale generation
Parallelizes locale generation based on `BR2_JLEVEL` setting.
Locale generation always runs during the finalize stage and can consume
a significant amount of time. Parallelizing it greatly reduces that time
on multi-core machines.
To parallelize it, we first invoke `localedef` for every locale in
parallel with the `--no-archive` option. This creates the intermediate
locale data instead of writing to the finally archive directly.
Then, we invoke `localedef` again once to create the archive from the
intermediate compiled locale data files.
We have to do it this way because `localedef` does not do any locking
when writing to the archive file, so calling it without `--no-archive`
concurrently could result in a corrupt archive file or an archive file
that is missing some locales.
While we're at it, make two additional improvements:
- Remove locale-archive before adding to it. Otherwise, repeated
applications of target-finalize will keep on growing the file.
- Sort the locales when creating locale-archive so its contents are
reproducible.
We use `find` to collect the installed locales rather than LOCALES. This
makes it possible for something else (skeleton, overlay, custom package)
to create and install additional locales and still have them added to
locale-archive.
Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com>
[Arnout:
- Remove -j$(PARALLEL_JOBS), it's already part of $(MAKE)
- Remove HOST_DIR, TARGET_DIR, STAGING_DIR, they're already exported
- Extend commit message
]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-01-03 18:15:25 +01:00
|
|
|
ENDIAN=$(call LOWERCASE,$(BR2_ENDIAN)) \
|
|
|
|
|
LOCALES="$(GLIBC_GENERATE_LOCALES)" \
|
|
|
|
|
Q=$(Q)
|
2014-06-27 14:15:58 +02:00
|
|
|
endef
|
2014-11-13 23:17:23 +01:00
|
|
|
TARGET_FINALIZE_HOOKS += GENERATE_GLIBC_LOCALES
|
2014-06-27 14:15:58 +02:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-29 17:32:34 +02:00
|
|
|
ifeq ($(BR2_ENABLE_LOCALE_PURGE),y)
|
|
|
|
|
LOCALE_WHITELIST = $(BUILD_DIR)/locales.nopurge
|
|
|
|
|
LOCALE_NOPURGE = $(call qstrip,$(BR2_ENABLE_LOCALE_WHITELIST))
|
|
|
|
|
|
2015-07-14 01:45:28 +02:00
|
|
|
# This piece of junk does the following:
|
|
|
|
|
# First collect the whitelist in a file.
|
|
|
|
|
# Then go over all the locale dirs and for each subdir, check if it exists
|
|
|
|
|
# in the whitelist file. If it doesn't, kill it.
|
|
|
|
|
# Finally, specifically for X11, regenerate locale.dir from the whitelist.
|
2014-06-27 14:15:55 +02:00
|
|
|
define PURGE_LOCALES
|
2020-06-15 13:16:43 +02:00
|
|
|
printf '%s\n' $(LOCALE_NOPURGE) locale-archive > $(LOCALE_WHITELIST)
|
2014-04-29 17:32:34 +02:00
|
|
|
|
Makefile: fix locale purge when BR2_PER_PACKAGE_DIRECTORIES=y
With BR2_PER_PACKAGE_DIRECTORIES=y, we have the following code in the
main Makefile:
target-finalize: $(PACKAGES) $(TARGET_DIR) host-finalize
@$(call MESSAGE,"Finalizing target directory")
$(call per-package-rsync,$(sort $(PACKAGES)),target,$(TARGET_DIR))
$(foreach hook,$(TARGET_FINALIZE_HOOKS),$($(hook))$(sep))
The per-package-rsync call creates the global $(TARGET_DIR) from the
per-package $(TARGET_DIR). Then, we call the TARGET_FINALIZE_HOOKS.
One of the TARGET_FINALIZE_HOOKS, PURGE_LOCALES, remove locales that
are not desired by the user. It does so using a loop with the
$(wildcard ...) function.
However, the $(wildcard ...) function is expanded at the moment the
rule is evaluated. And with per-package directory, at the time the
rule is evaluated, the global $(TARGET_DIR) is empty, so $(wildcard
...) will return nothing. It is indeed only after the call to
per-package-rsync that the TARGET_DIR will be populated.
This commit fixes that by moving away from $(wildcard ...) and use a
shell test instead, since we are anyway in big block of shell code.
With this, locales are properly purged again when
BR2_PER_PACKAGE_DIRECTORIES=y.
Fixes: c4e6d5c8be6ada8e7c60950e3b499c55d48761cb ("core: implement per-package SDK and target")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- make the style look like the code around (no space in front of ;)
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-03-16 16:46:23 +01:00
|
|
|
for dir in $(addprefix $(TARGET_DIR),/usr/share/locale /usr/share/X11/locale /usr/lib/locale); \
|
2014-04-29 17:32:34 +02:00
|
|
|
do \
|
Makefile: fix locale purge when BR2_PER_PACKAGE_DIRECTORIES=y
With BR2_PER_PACKAGE_DIRECTORIES=y, we have the following code in the
main Makefile:
target-finalize: $(PACKAGES) $(TARGET_DIR) host-finalize
@$(call MESSAGE,"Finalizing target directory")
$(call per-package-rsync,$(sort $(PACKAGES)),target,$(TARGET_DIR))
$(foreach hook,$(TARGET_FINALIZE_HOOKS),$($(hook))$(sep))
The per-package-rsync call creates the global $(TARGET_DIR) from the
per-package $(TARGET_DIR). Then, we call the TARGET_FINALIZE_HOOKS.
One of the TARGET_FINALIZE_HOOKS, PURGE_LOCALES, remove locales that
are not desired by the user. It does so using a loop with the
$(wildcard ...) function.
However, the $(wildcard ...) function is expanded at the moment the
rule is evaluated. And with per-package directory, at the time the
rule is evaluated, the global $(TARGET_DIR) is empty, so $(wildcard
...) will return nothing. It is indeed only after the call to
per-package-rsync that the TARGET_DIR will be populated.
This commit fixes that by moving away from $(wildcard ...) and use a
shell test instead, since we are anyway in big block of shell code.
With this, locales are properly purged again when
BR2_PER_PACKAGE_DIRECTORIES=y.
Fixes: c4e6d5c8be6ada8e7c60950e3b499c55d48761cb ("core: implement per-package SDK and target")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- make the style look like the code around (no space in front of ;)
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-03-16 16:46:23 +01:00
|
|
|
if [ ! -d $$dir ]; then continue; fi; \
|
2015-07-14 01:45:27 +02:00
|
|
|
for langdir in $$dir/*; \
|
2014-04-29 17:32:34 +02:00
|
|
|
do \
|
2016-03-08 22:02:15 +01:00
|
|
|
if [ -e "$${langdir}" ]; \
|
|
|
|
|
then \
|
|
|
|
|
grep -qx "$${langdir##*/}" $(LOCALE_WHITELIST) || rm -rf $$langdir; \
|
|
|
|
|
fi \
|
2014-04-29 17:32:34 +02:00
|
|
|
done; \
|
|
|
|
|
done
|
2015-07-14 01:45:28 +02:00
|
|
|
if [ -d $(TARGET_DIR)/usr/share/X11/locale ]; \
|
|
|
|
|
then \
|
|
|
|
|
for lang in $(LOCALE_NOPURGE); \
|
|
|
|
|
do \
|
|
|
|
|
if [ -f $(TARGET_DIR)/usr/share/X11/locale/$$lang/XLC_LOCALE ]; \
|
|
|
|
|
then \
|
|
|
|
|
echo "$$lang/XLC_LOCALE: $$lang"; \
|
|
|
|
|
fi \
|
|
|
|
|
done > $(TARGET_DIR)/usr/share/X11/locale/locale.dir; \
|
|
|
|
|
fi
|
2014-04-29 17:32:34 +02:00
|
|
|
endef
|
2014-06-27 14:15:55 +02:00
|
|
|
TARGET_FINALIZE_HOOKS += PURGE_LOCALES
|
2014-04-29 17:32:34 +02:00
|
|
|
endif
|
|
|
|
|
|
2014-02-20 15:26:18 +01:00
|
|
|
$(TARGETS_ROOTFS): target-finalize
|
|
|
|
|
|
2018-03-31 11:05:51 +02:00
|
|
|
# Avoid the rootfs name leaking down the dependency chain
|
|
|
|
|
target-finalize: ROOTFS=
|
|
|
|
|
|
2020-03-18 16:58:11 +01:00
|
|
|
TARGET_DIR_FILES_LISTS = $(sort $(wildcard $(BUILD_DIR)/*/.files-list.txt))
|
|
|
|
|
HOST_DIR_FILES_LISTS = $(sort $(wildcard $(BUILD_DIR)/*/.files-list-host.txt))
|
|
|
|
|
STAGING_DIR_FILES_LISTS = $(sort $(wildcard $(BUILD_DIR)/*/.files-list-staging.txt))
|
|
|
|
|
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
.PHONY: host-finalize
|
|
|
|
|
host-finalize: $(PACKAGES) $(HOST_DIR) $(HOST_DIR_SYMLINK)
|
|
|
|
|
@$(call MESSAGE,"Finalizing host directory")
|
2023-10-17 23:01:20 +02:00
|
|
|
$(call per-package-rsync,$(sort $(PACKAGES)),host,$(HOST_DIR),copy)
|
Makefile: rework main directory creation logic
In the current code, the creation of the main output directories
(BUILD_DIR, STAGING_DIR, HOST_DIR, TARGET_DIR, etc.) is done by a
global "dirs" target. While this works fine in the current situation,
it doesn't work well in a context where per-package host and target
directories are used.
For example, with the current code and per-package host directories,
the output/staging symbolic link ends up being created as a link to
the per-package package sysroot directory of the first package being
built, instead of the global sysroot.
This commit reworks the creation of those directories by having the
package/pkg-generic.mk code ensure that the build directory, target
directory, host directory, staging directory and binaries directory
exist before they are needed.
Two new targets, host-finalize and staging-finalize are added in the
main Makefile to create the compatibility symlinks for host and
staging directories. They will be extended later with additional logic
for per-package directories.
Thanks to those changes, the global "dirs" target is entirely removed.
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>
2018-11-23 15:58:08 +01:00
|
|
|
|
|
|
|
|
.PHONY: staging-finalize
|
Makefile: don't recreate staging symlink if it exists
Create the staging symlink the same way as the host symlink. This means
using a make dependency rather than recreating it every time.
In coreutils versions below 8.27, re-creation of symbolic links was not
atomic. This means that there is a period in time where the existing link is
removed, before the new one is created. In coreutils 8.27 this was fixed,
see [1]. Note that CentOS 7 ships with coreutils 8.22.
In the following scenario, this is a problem:
- an application is compiled using the sysroot prepared by Buildroot and
links against Xenomai userspace libraries, but its build process is steered
from outside of Buildroot
- to know the correct flags, the application makefile uses the 'xeno-config'
file to request them, and passes DESTDIR=/buildroot/output/staging
- the xeno-config responds with flags based on the path
'/buildroot/output/staging/...'
- while the application build is ongoing, a 'make' happens in Buildroot,
causing the 'staging' symlink to be recreated (even though it already
existed)
- when exactly at this time, the application calls the compiler with -I
flags pointing to output/staging, the build fails with:
-I/buildroot/output/staging/usr/include/xenomai/mercury: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/xenomai: Error: ^ is not a directory
-I/buildroot/output/staging/usr/include/xenomai/psos: Error: ^ is not a directory
Failed: ** ^ *
Work around this problem by only creating the staging symlink once, similar
to how the host symlink (if any) is created.
See also commit d0f4f95e390bcb1c953efa125f5277a8a235396e which changed the
way these symlinks are made. The reasoning in this commit is to move away
from the 'dirs' target.
[1] https://github.com/coreutils/coreutils/commit/376967889ed7ed561e46ff6d88a66779db62737a
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-02-18 16:01:00 +01:00
|
|
|
staging-finalize: $(STAGING_DIR_SYMLINK)
|
Makefile: rework main directory creation logic
In the current code, the creation of the main output directories
(BUILD_DIR, STAGING_DIR, HOST_DIR, TARGET_DIR, etc.) is done by a
global "dirs" target. While this works fine in the current situation,
it doesn't work well in a context where per-package host and target
directories are used.
For example, with the current code and per-package host directories,
the output/staging symbolic link ends up being created as a link to
the per-package package sysroot directory of the first package being
built, instead of the global sysroot.
This commit reworks the creation of those directories by having the
package/pkg-generic.mk code ensure that the build directory, target
directory, host directory, staging directory and binaries directory
exist before they are needed.
Two new targets, host-finalize and staging-finalize are added in the
main Makefile to create the compatibility symlinks for host and
staging directories. They will be extended later with additional logic
for per-package directories.
Thanks to those changes, the global "dirs" target is entirely removed.
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>
2018-11-23 15:58:08 +01:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: target-finalize
|
core: implement per-package SDK and target
This commit implements the core of the move to per-package SDK and
target directories. The main idea is that instead of having a global
output/host and output/target in which all packages install files, we
switch to per-package host and target directories, that only contain
their explicit dependencies.
There are two main benefits:
- Packages will now see only the dependencies they explicitly list in
their <pkg>_DEPENDENCIES variable, and the recursive dependencies
thereof.
- We can support top-level parallel build properly, because a package
only "sees" its own host directory and target directory, isolated
from the build of other packages that can happen in parallel.
It works as follows:
- A new output/per-package/ directory is created, which will contain
one sub-directory per package, and inside it, a "host" directory
and a "target" directory:
output/per-package/busybox/target
output/per-package/busybox/host
output/per-package/host-fakeroot/target
output/per-package/host-fakeroot/host
This output/per-package/ directory is PER_PACKAGE_DIR.
- The global TARGET_DIR and HOST_DIR variable now automatically point
to the per-package directory when PKG is defined. So whenever a
package references $(HOST_DIR) or $(TARGET_DIR) in its build
process, it effectively references the per-package host/target
directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it
is handled as well.
- Of course, packages have dependencies, so those dependencies must
be installed in the per-package host and target directories. To do
so, we simply rsync (using hard links to save space and time) the
host and target directories of the direct dependencies of the
package to the current package host and target directories.
We only need to take care of direct dependencies (and not
recursively all dependencies), because we accumulate into those
per-package host and target directories the files installed by the
dependencies. Note that this only works because we make the
assumption that one package does *not* overwrite files installed by
another package.
This is done for "extract dependencies" at the beginning of the
extract step, and for "normal dependencies" at the beginning of the
configure step.
This is basically enough to make per-package SDK and target work. The
only gotcha is that at the end of the build, output/target and
output/host are empty, which means that:
- The filesystem image creation code cannot work.
- We don't have a SDK to build code outside of Buildroot.
In order to fix this, this commit extends the target-finalize step so
that it starts by populating output/target and output/host by
rsync-ing into them the target and host directories of all packages
listed in the $(PACKAGES) variable. It is necessary to do this
sequentially in the target-finalize step and not in each
package. Doing it in package installation means that it can be done in
parallel. In that case, there is a chance that two rsyncs are creating
the same hardlink or directory at the same time, which makes one of
them fail.
This change to per-package directories has an impact on the RPATH
built into the host binaries, as those RPATH now point to various
per-package host directories, and no longer to the global host
directory. We do not try to rewrite such RPATHs during the build as
having such RPATHs is perfectly fine, but we still need to handle two
fallouts from this change:
- The check-host-rpath script, which verifies at the end of each
package installation that it has the appropriate RPATH, is modified
to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is
a correct RPAT.
- The fix-rpath script, which mungles the RPATH mainly for the SDK
preparation, is modified to rewrite the RPATH to not point to
per-package directories. Indeed the patchelf --make-rpath-relative
call only works if the RPATH points to the ROOTDIR passed as
argument, and this ROOTDIR is the global host directory. Rewriting
the RPATH to not point to per-package host directories prior to
this is an easy solution to this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
|
|
|
target-finalize: $(PACKAGES) $(TARGET_DIR) host-finalize
|
2014-05-12 16:19:27 +02:00
|
|
|
@$(call MESSAGE,"Finalizing target directory")
|
2023-10-17 23:01:20 +02:00
|
|
|
$(call per-package-rsync,$(sort $(PACKAGES)),target,$(TARGET_DIR),copy)
|
2014-06-27 14:15:55 +02:00
|
|
|
$(foreach hook,$(TARGET_FINALIZE_HOOKS),$($(hook))$(sep))
|
2012-10-02 10:52:15 +02:00
|
|
|
rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \
|
2013-03-06 08:14:26 +01:00
|
|
|
$(TARGET_DIR)/usr/lib/pkgconfig $(TARGET_DIR)/usr/share/pkgconfig \
|
2020-02-17 22:23:24 +01:00
|
|
|
$(TARGET_DIR)/usr/lib/cmake $(TARGET_DIR)/usr/share/cmake \
|
2022-02-22 11:22:08 +01:00
|
|
|
$(TARGET_DIR)/usr/lib/rpm $(TARGET_DIR)/usr/doc
|
2013-03-06 08:14:26 +01:00
|
|
|
find $(TARGET_DIR)/usr/{lib,share}/ -name '*.cmake' -print0 | xargs -0 rm -f
|
2016-11-09 11:57:27 +01:00
|
|
|
find $(TARGET_DIR)/lib/ $(TARGET_DIR)/usr/lib/ $(TARGET_DIR)/usr/libexec/ \
|
2020-02-17 22:23:24 +01:00
|
|
|
\( -name '*.a' -o -name '*.la' -o -name '*.prl' \) -print0 | xargs -0 rm -f
|
2010-07-24 21:29:56 +02:00
|
|
|
ifneq ($(BR2_PACKAGE_GDB),y)
|
|
|
|
|
rm -rf $(TARGET_DIR)/usr/share/gdb
|
2015-07-12 17:25:57 +02:00
|
|
|
endif
|
|
|
|
|
ifneq ($(BR2_PACKAGE_BASH),y)
|
|
|
|
|
rm -rf $(TARGET_DIR)/usr/share/bash-completion
|
2020-07-14 04:24:59 +02:00
|
|
|
rm -rf $(TARGET_DIR)/etc/bash_completion.d
|
2015-07-12 17:25:57 +02:00
|
|
|
endif
|
|
|
|
|
ifneq ($(BR2_PACKAGE_ZSH),y)
|
|
|
|
|
rm -rf $(TARGET_DIR)/usr/share/zsh
|
2010-07-24 21:29:56 +02:00
|
|
|
endif
|
2009-04-07 23:04:31 +02:00
|
|
|
rm -rf $(TARGET_DIR)/usr/man $(TARGET_DIR)/usr/share/man
|
|
|
|
|
rm -rf $(TARGET_DIR)/usr/info $(TARGET_DIR)/usr/share/info
|
2010-04-10 22:42:45 +02:00
|
|
|
rm -rf $(TARGET_DIR)/usr/doc $(TARGET_DIR)/usr/share/doc
|
2010-05-05 12:09:36 +02:00
|
|
|
rm -rf $(TARGET_DIR)/usr/share/gtk-doc
|
2016-11-22 21:53:33 +01:00
|
|
|
rmdir $(TARGET_DIR)/usr/share 2>/dev/null || true
|
2020-07-14 04:25:54 +02:00
|
|
|
ifneq ($(BR2_ENABLE_DEBUG):$(BR2_STRIP_strip),y:)
|
|
|
|
|
rm -rf $(TARGET_DIR)/lib/debug $(TARGET_DIR)/usr/lib/debug
|
|
|
|
|
endif
|
2015-03-18 16:10:29 +01:00
|
|
|
$(STRIP_FIND_CMD) | xargs -0 $(STRIPCMD) 2>/dev/null || true
|
2018-07-03 12:06:14 +02:00
|
|
|
$(STRIP_FIND_SPECIAL_LIBS_CMD) | xargs -0 -r $(STRIPCMD) $(STRIP_STRIP_DEBUG) 2>/dev/null || true
|
2010-11-18 00:55:43 +01:00
|
|
|
|
2016-01-01 22:23:39 +01:00
|
|
|
test -f $(TARGET_DIR)/etc/ld.so.conf && \
|
|
|
|
|
{ echo "ERROR: we shouldn't have a /etc/ld.so.conf file"; exit 1; } || true
|
|
|
|
|
test -d $(TARGET_DIR)/etc/ld.so.conf.d && \
|
|
|
|
|
{ echo "ERROR: we shouldn't have a /etc/ld.so.conf.d directory"; exit 1; } || true
|
2010-08-30 22:52:18 +02:00
|
|
|
mkdir -p $(TARGET_DIR)/etc
|
2012-02-14 12:58:25 +01:00
|
|
|
( \
|
|
|
|
|
echo "NAME=Buildroot"; \
|
|
|
|
|
echo "VERSION=$(BR2_VERSION_FULL)"; \
|
|
|
|
|
echo "ID=buildroot"; \
|
|
|
|
|
echo "VERSION_ID=$(BR2_VERSION)"; \
|
|
|
|
|
echo "PRETTY_NAME=\"Buildroot $(BR2_VERSION)\"" \
|
2018-01-24 00:13:50 +01:00
|
|
|
) > $(TARGET_DIR)/usr/lib/os-release
|
|
|
|
|
ln -sf ../usr/lib/os-release $(TARGET_DIR)/etc
|
2009-09-30 17:40:24 +02:00
|
|
|
|
2017-07-20 16:35:16 +02:00
|
|
|
@$(call MESSAGE,"Sanitizing RPATH in target tree")
|
2022-10-20 13:55:12 +02:00
|
|
|
PARALLEL_JOBS=$(PARALLEL_JOBS) \
|
|
|
|
|
PER_PACKAGE_DIR=$(PER_PACKAGE_DIR) \
|
|
|
|
|
$(TOPDIR)/support/scripts/fix-rpath target
|
2017-07-20 16:35:16 +02:00
|
|
|
|
2018-05-07 16:44:29 +02:00
|
|
|
# For a merged /usr, ensure that /lib, /bin and /sbin and their /usr
|
|
|
|
|
# counterparts are appropriately setup as symlinks ones to the others.
|
|
|
|
|
ifeq ($(BR2_ROOTFS_MERGED_USR),y)
|
|
|
|
|
|
2020-08-29 14:56:38 +02:00
|
|
|
$(foreach d, $(call qstrip,$(BR2_ROOTFS_OVERLAY)), \
|
|
|
|
|
@$(call MESSAGE,"Sanity check in overlay $(d)")$(sep) \
|
|
|
|
|
$(Q)not_merged_dirs="$$(support/scripts/check-merged-usr.sh $(d))"; \
|
2018-05-07 16:44:29 +02:00
|
|
|
test -n "$$not_merged_dirs" && { \
|
|
|
|
|
echo "ERROR: The overlay in $(d) is not" \
|
|
|
|
|
"using a merged /usr for the following directories:" \
|
|
|
|
|
$$not_merged_dirs; \
|
|
|
|
|
exit 1; \
|
|
|
|
|
} || true$(sep))
|
|
|
|
|
|
|
|
|
|
endif # merged /usr
|
|
|
|
|
|
2020-08-29 14:56:38 +02:00
|
|
|
$(foreach d, $(call qstrip,$(BR2_ROOTFS_OVERLAY)), \
|
|
|
|
|
@$(call MESSAGE,"Copying overlay $(d)")$(sep) \
|
|
|
|
|
$(Q)$(call SYSTEM_RSYNC,$(d),$(TARGET_DIR))$(sep))
|
2013-02-05 08:16:00 +01:00
|
|
|
|
2020-08-29 14:20:54 +02:00
|
|
|
$(Q)$(if $(TARGET_DIR_FILES_LISTS), \
|
2020-03-18 16:58:11 +01:00
|
|
|
cat $(TARGET_DIR_FILES_LISTS)) > $(BUILD_DIR)/packages-file-list.txt
|
2020-08-29 14:20:54 +02:00
|
|
|
$(Q)$(if $(HOST_DIR_FILES_LISTS), \
|
2020-03-18 16:58:11 +01:00
|
|
|
cat $(HOST_DIR_FILES_LISTS)) > $(BUILD_DIR)/packages-file-list-host.txt
|
2020-08-29 14:20:54 +02:00
|
|
|
$(Q)$(if $(STAGING_DIR_FILES_LISTS), \
|
2020-03-18 16:58:11 +01:00
|
|
|
cat $(STAGING_DIR_FILES_LISTS)) > $(BUILD_DIR)/packages-file-list-staging.txt
|
core: fix packages-file-list.txt after an incremental build
The package instrumentation step 'step_pkg_size' is populating the files:
output/build/packages-file-list.txt
output/build/packages-file-list-staging.txt
output/build/packages-file-list-host.txt
by comparing the list of files before and after installation of a package,
with some clever tricks to detect changes to existing files etc.
As an optimization, instead of gathering this list before and after each
package, where the 'after-state' of one package is the same as the
'before-state' of the next package, only the 'after-state' is used and
is shared between packages.
This works fine, except at the end of the build, as explained next.
In the target-finalize step, many files will be touched. For example, files
like /etc/hosts, /etc/os-release, but also all object files that are
stripped, and all files touched by post-build scripts or created by rootfs
overlays. This means that the 'after-state' of the last package does not
reflect the actual situation after target-finalize is run.
For a single complete build this poses no problem. But, if one incrementally
rebuilds a package after the initial build, e.g. with 'make foo-rebuild',
then all changes that happened in target-finalize at the end of the initial
build (the 'after-state' of the last package built) will be detected as
changes caused by the rebuild of package foo. As a result, all these files
will incorrectly be treated as 'owned' by package foo.
Correct this situation by capturing a new state at the end of
target-finalize, so that the 'before-state' of an incremental build will be
correct.
Note: the reasoning above talks about packages-file-list.txt and
target-finalize, but also applies to
packages-file-list-staging.txt/staging-finalize and
packages-file-list-host.txt/host-finalize.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-02-14 20:57:33 +01:00
|
|
|
|
2020-08-29 14:56:38 +02:00
|
|
|
$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_BUILD_SCRIPT)), \
|
|
|
|
|
@$(call MESSAGE,"Executing post-build script $(s)")$(sep) \
|
|
|
|
|
$(Q)$(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
|
2020-03-18 16:58:13 +01:00
|
|
|
|
|
|
|
|
touch $(TARGET_DIR)/usr
|
|
|
|
|
|
2022-07-28 21:37:26 +02:00
|
|
|
# Note: this will run in the filesystem context, so will use a copy
|
|
|
|
|
# of target/, not the real one, so the files are still available on
|
|
|
|
|
# re-builds (foo-rebuild, etc...)
|
|
|
|
|
define ROOTFS_RM_HWDB_DATA
|
|
|
|
|
rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/ $(TARGET_DIR)/etc/udev/hwdb.d/
|
|
|
|
|
endef
|
|
|
|
|
ROOTFS_PRE_CMD_HOOKS += ROOTFS_RM_HWDB_DATA
|
|
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: target-post-image
|
Makefile: rework main directory creation logic
In the current code, the creation of the main output directories
(BUILD_DIR, STAGING_DIR, HOST_DIR, TARGET_DIR, etc.) is done by a
global "dirs" target. While this works fine in the current situation,
it doesn't work well in a context where per-package host and target
directories are used.
For example, with the current code and per-package host directories,
the output/staging symbolic link ends up being created as a link to
the per-package package sysroot directory of the first package being
built, instead of the global sysroot.
This commit reworks the creation of those directories by having the
package/pkg-generic.mk code ensure that the build directory, target
directory, host directory, staging directory and binaries directory
exist before they are needed.
Two new targets, host-finalize and staging-finalize are added in the
main Makefile to create the compatibility symlinks for host and
staging directories. They will be extended later with additional logic
for per-package directories.
Thanks to those changes, the global "dirs" target is entirely removed.
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>
2018-11-23 15:58:08 +01:00
|
|
|
target-post-image: $(TARGETS_ROOTFS) target-finalize staging-finalize
|
fs: remove intermediate artefacts
Each of the intermediate, per-rootfs target directories, as well as the
intermediate tarball, can take quite some place, and is mostly a
duplication of what's already in target/. The only delta, if any, would
be the tweaks made by the filesystem image generations, but those tweaks
are most probably only meaningful when seen as root.
We normally do not remove intermediate files, but those can be quite
large, and are not directly usable by, nor accessible to the user.
So, get rid of them once the filesystem has been generated.
This does not need to be done in fakeroot.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-31 11:06:01 +02:00
|
|
|
@rm -f $(ROOTFS_COMMON_TAR)
|
2019-08-04 17:07:07 +02:00
|
|
|
$(Q)mkdir -p $(BINARIES_DIR)
|
2013-02-07 12:58:43 +01:00
|
|
|
@$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_IMAGE_SCRIPT)), \
|
2013-04-08 08:50:15 +02:00
|
|
|
$(call MESSAGE,"Executing post-image script $(s)"); \
|
2014-03-10 21:51:33 +01:00
|
|
|
$(EXTRA_ENV) $(s) $(BINARIES_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
|
2013-02-07 12:58:43 +01:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: source
|
2015-04-26 11:51:12 +02:00
|
|
|
source: $(foreach p,$(PACKAGES),$(p)-all-source)
|
2002-04-26 13:45:55 +02:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: _external-deps external-deps
|
2015-04-26 11:51:01 +02:00
|
|
|
_external-deps: $(foreach p,$(PACKAGES),$(p)-all-external-deps)
|
2008-03-04 13:19:16 +01:00
|
|
|
external-deps:
|
2015-04-26 11:51:01 +02:00
|
|
|
@$(MAKE1) -Bs $(EXTRAMAKEARGS) _external-deps | sort -u
|
2008-03-04 13:19:16 +01:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: legal-info-clean
|
2012-05-17 19:33:00 +02:00
|
|
|
legal-info-clean:
|
|
|
|
|
@rm -fr $(LEGAL_INFO_DIR)
|
|
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: legal-info-prepare
|
2012-05-17 19:33:00 +02:00
|
|
|
legal-info-prepare: $(LEGAL_INFO_DIR)
|
2017-07-05 13:20:43 +02:00
|
|
|
@$(call MESSAGE,"Buildroot $(BR2_VERSION_FULL) Collecting legal info")
|
support/download: teach dl-wrapper to handle more than one hash file
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
So, we need our download helpers to be able to accept more than one hash
file to lookup for hashes.
Extend the dl-wrapper and the check-hash helpers thusly, and update the
legal-info accordingly.
Note that, to be able to pass more than one hash file, we also need to
re-order the arguments passed to support/download/check-hash, which also
impies some shuffling in the three places it is called:
- 2 in dl-wrapper
- 1 in the legal-info infra
That in turn also requires that the legal-license-file macro args get
re-ordered to have the hash file last; we take the opportunity to also
move the HOST/TARGET arg to be first, like in the other legal-info
macros.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
|
|
|
@$(call legal-license-file,HOST,buildroot,buildroot,COPYING,COPYING,support/legal-info/buildroot.hash)
|
2018-10-21 13:59:24 +02:00
|
|
|
@$(call legal-manifest,TARGET,PACKAGE,VERSION,LICENSE,LICENSE FILES,SOURCE ARCHIVE,SOURCE SITE,DEPENDENCIES WITH LICENSES)
|
|
|
|
|
@$(call legal-manifest,HOST,PACKAGE,VERSION,LICENSE,LICENSE FILES,SOURCE ARCHIVE,SOURCE SITE,DEPENDENCIES WITH LICENSES)
|
2018-10-21 13:59:23 +02:00
|
|
|
@$(call legal-manifest,HOST,buildroot,$(BR2_VERSION_FULL),GPL-2.0+,COPYING,not saved,not saved)
|
2012-05-17 19:33:00 +02:00
|
|
|
@$(call legal-warning,the Buildroot source code has not been saved)
|
2014-02-04 16:18:52 +01:00
|
|
|
@cp $(BR2_CONFIG) $(LEGAL_INFO_DIR)/buildroot.config
|
2012-05-17 19:33:00 +02:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: legal-info
|
Makefile: rework main directory creation logic
In the current code, the creation of the main output directories
(BUILD_DIR, STAGING_DIR, HOST_DIR, TARGET_DIR, etc.) is done by a
global "dirs" target. While this works fine in the current situation,
it doesn't work well in a context where per-package host and target
directories are used.
For example, with the current code and per-package host directories,
the output/staging symbolic link ends up being created as a link to
the per-package package sysroot directory of the first package being
built, instead of the global sysroot.
This commit reworks the creation of those directories by having the
package/pkg-generic.mk code ensure that the build directory, target
directory, host directory, staging directory and binaries directory
exist before they are needed.
Two new targets, host-finalize and staging-finalize are added in the
main Makefile to create the compatibility symlinks for host and
staging directories. They will be extended later with additional logic
for per-package directories.
Thanks to those changes, the global "dirs" target is entirely removed.
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>
2018-11-23 15:58:08 +01:00
|
|
|
legal-info: legal-info-clean legal-info-prepare $(foreach p,$(PACKAGES),$(p)-all-legal-info) \
|
2013-11-12 09:47:59 +01:00
|
|
|
$(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST)
|
2012-05-17 19:33:00 +02:00
|
|
|
@cat support/legal-info/README.header >>$(LEGAL_REPORT)
|
|
|
|
|
@if [ -r $(LEGAL_WARNINGS) ]; then \
|
|
|
|
|
cat support/legal-info/README.warnings-header \
|
|
|
|
|
$(LEGAL_WARNINGS) >>$(LEGAL_REPORT); \
|
|
|
|
|
cat $(LEGAL_WARNINGS); fi
|
|
|
|
|
@rm -f $(LEGAL_WARNINGS)
|
2016-05-07 18:14:36 +02:00
|
|
|
@(cd $(LEGAL_INFO_DIR); \
|
|
|
|
|
find * -type f -exec sha256sum {} + | LC_ALL=C sort -k2 \
|
|
|
|
|
>.legal-info.sha256; \
|
|
|
|
|
mv .legal-info.sha256 legal-info.sha256)
|
|
|
|
|
@echo "Legal info produced in $(LEGAL_INFO_DIR)"
|
2012-05-17 19:33:00 +02:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: show-targets
|
2010-05-13 19:20:33 +02:00
|
|
|
show-targets:
|
2017-11-12 18:45:39 +01:00
|
|
|
@echo $(sort $(PACKAGES)) $(sort $(TARGETS_ROOTFS))
|
2010-05-13 19:20:33 +02:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: show-build-order
|
2017-04-02 15:03:38 +02:00
|
|
|
show-build-order: $(patsubst %,%-show-build-order,$(PACKAGES))
|
|
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: graph-build
|
2013-12-28 18:39:11 +01:00
|
|
|
graph-build: $(O)/build/build-time.log
|
2015-02-05 22:19:56 +01:00
|
|
|
@install -d $(GRAPHS_DIR)
|
2013-12-28 18:39:11 +01:00
|
|
|
$(foreach o,name build duration,./support/scripts/graph-build-time \
|
|
|
|
|
--type=histogram --order=$(o) --input=$(<) \
|
2015-02-05 22:19:56 +01:00
|
|
|
--output=$(GRAPHS_DIR)/build.hist-$(o).$(BR_GRAPH_OUT) \
|
2014-02-23 16:59:11 +01:00
|
|
|
$(if $(BR2_GRAPH_ALT),--alternate-colors)$(sep))
|
2013-12-28 18:39:11 +01:00
|
|
|
$(foreach t,packages steps,./support/scripts/graph-build-time \
|
|
|
|
|
--type=pie-$(t) --input=$(<) \
|
2015-02-05 22:19:56 +01:00
|
|
|
--output=$(GRAPHS_DIR)/build.pie-$(t).$(BR_GRAPH_OUT) \
|
2014-02-23 16:59:11 +01:00
|
|
|
$(if $(BR2_GRAPH_ALT),--alternate-colors)$(sep))
|
2022-02-09 21:30:26 +01:00
|
|
|
./support/scripts/graph-build-time --type=timeline --input=$(<) \
|
|
|
|
|
--output=$(GRAPHS_DIR)/build.timeline.$(BR_GRAPH_OUT) \
|
|
|
|
|
$(if $(BR2_GRAPH_ALT),--alternate-colors)
|
2013-12-28 18:39:11 +01:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: graph-depends-requirements
|
2014-06-17 11:33:54 +02:00
|
|
|
graph-depends-requirements:
|
2014-06-13 14:17:19 +02:00
|
|
|
@dot -? >/dev/null 2>&1 || \
|
2014-06-17 11:33:54 +02:00
|
|
|
{ echo "ERROR: The 'dot' program from Graphviz is needed for graph-depends" >&2; exit 1; }
|
|
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: graph-depends
|
2014-06-17 11:33:54 +02:00
|
|
|
graph-depends: graph-depends-requirements
|
2015-02-05 22:19:56 +01:00
|
|
|
@$(INSTALL) -d $(GRAPHS_DIR)
|
2014-01-07 23:46:04 +01:00
|
|
|
@cd "$(CONFIG_DIR)"; \
|
2014-05-16 23:05:13 +02:00
|
|
|
$(TOPDIR)/support/scripts/graph-depends $(BR2_GRAPH_DEPS_OPTS) \
|
2016-10-23 19:19:44 +02:00
|
|
|
--direct -o $(GRAPHS_DIR)/$(@).dot
|
2016-02-07 22:34:26 +01:00
|
|
|
dot $(BR2_GRAPH_DOT_OPTS) -T$(BR_GRAPH_OUT) \
|
|
|
|
|
-o $(GRAPHS_DIR)/$(@).$(BR_GRAPH_OUT) \
|
|
|
|
|
$(GRAPHS_DIR)/$(@).dot
|
2013-12-28 18:39:12 +01:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: graph-size
|
2015-10-17 15:33:44 +02:00
|
|
|
graph-size:
|
|
|
|
|
$(Q)mkdir -p $(GRAPHS_DIR)
|
|
|
|
|
$(Q)$(TOPDIR)/support/scripts/size-stats --builddir $(BASE_DIR) \
|
|
|
|
|
--graph $(GRAPHS_DIR)/graph-size.$(BR_GRAPH_OUT) \
|
|
|
|
|
--file-size-csv $(GRAPHS_DIR)/file-size-stats.csv \
|
support/graph-size: add option to change percentage to group in Others
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>
2019-08-17 19:18:27 +02:00
|
|
|
--package-size-csv $(GRAPHS_DIR)/package-size-stats.csv \
|
|
|
|
|
$(BR2_GRAPH_SIZE_OPTS)
|
2015-10-17 15:33:44 +02:00
|
|
|
|
2017-06-15 00:11:32 +02:00
|
|
|
.PHONY: check-dependencies
|
2016-02-07 22:34:29 +01:00
|
|
|
check-dependencies:
|
|
|
|
|
@cd "$(CONFIG_DIR)"; \
|
|
|
|
|
$(TOPDIR)/support/scripts/graph-depends -C
|
|
|
|
|
|
core: introduce new global show-info
Users are increasingly trying to extract information about packages. For
example, they might need to get the list of URIs, or the dependencies of
a package.
Although we do have a bunch of rules to generate some of that, this is
done in ad-hoc way, with most of the output formats just ad-hoc, raw,
unformatted blurbs, mostly internal data dumped as-is.
Introduce a new rule, show-info, that provides a properly formatted
output of all the meta-information about packages: name, type, version,
licenses, dependencies...
We choose to use JSON as the output format, because it is pretty
versatile, has parsers in virtually all languages, has tools to parse
from the shell (jq). It also closely matches Python data structure,
which makes it easy to use with our own internal tools as well. Finally,
JSON being a key-value store, allows for easy expanding the output
without requiring existing consumers to be updated; new, unknown keys
are simply ignored by those (as long as they are true JSON parsers).
The complex part of this change was the conditional output of parts of
the data: virtual packages have no source, version, license or
downloads, unlike non-virtual packages. Same goes for filesystems. We
use a wrapper macro, show-info, that de-multiplexes unto either the
package-related- or filesystem-related macros, and for packages, we also
use a detailed macro for non-virtual packages.
It is non-trivial to properly output correct JSON blurbs, especially
when trying to output an array of objects, like so, where the last item
shall not be followed by a comma: [ { ... }, { ... } ]
So, we use a trick (as sugegsted by Arnout), to $(subst) any pair of
",}" or ", }" or ",]" or ", ]" with only the respective closing symbol,
"}" or "]".
The whole stuff is $(strip)ed to make it a somewhat-minified JSON blurb
that fits on a single line with all spaces squashed (but still with
spaces, as it is not possible to differentiate spaces between JSON
elements from spaces inside JSON strings).
Reported-by: Thomas De Schampheleire <patrickdepinguin@gmail.com>
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: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-15 21:47:31 +02:00
|
|
|
.PHONY: show-info
|
|
|
|
|
show-info:
|
|
|
|
|
@:
|
|
|
|
|
$(info $(call clean-json, \
|
|
|
|
|
{ $(foreach p, \
|
|
|
|
|
$(sort $(foreach i,$(PACKAGES) $(TARGETS_ROOTFS), \
|
|
|
|
|
$(i) \
|
|
|
|
|
$($(call UPPERCASE,$(i))_FINAL_RECURSIVE_DEPENDENCIES) \
|
|
|
|
|
) \
|
|
|
|
|
), \
|
|
|
|
|
$(call json-info,$(call UPPERCASE,$(p)))$(comma) \
|
|
|
|
|
) } \
|
|
|
|
|
) \
|
|
|
|
|
)
|
|
|
|
|
|
2020-11-05 17:30:22 +01:00
|
|
|
.PHONY: pkg-stats
|
|
|
|
|
pkg-stats:
|
|
|
|
|
@cd "$(CONFIG_DIR)" ; \
|
|
|
|
|
$(TOPDIR)/support/scripts/pkg-stats -c \
|
|
|
|
|
--json $(O)/pkg-stats.json \
|
|
|
|
|
--html $(O)/pkg-stats.html \
|
|
|
|
|
--nvd-path $(DL_DIR)/buildroot-nvd
|
|
|
|
|
|
2007-09-29 15:58:30 +02:00
|
|
|
else # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
Makefile: unconfigured "make toolchain" should run report error
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>
2017-06-30 19:00:33 +02:00
|
|
|
# Some subdirectories are also package names. To avoid that "make linux"
|
|
|
|
|
# on an unconfigured tree produces "Nothing to be done", add an explicit
|
|
|
|
|
# rule for it.
|
Makefile: don't run "menuconfig" automatically
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>
2017-07-01 10:24:46 +02:00
|
|
|
# Also for 'all' we error out and ask the user to configure first.
|
Makefile: unconfigured "make toolchain" should run report error
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>
2017-06-30 19:00:33 +02:00
|
|
|
.PHONY: linux toolchain
|
2017-07-03 12:24:05 +02:00
|
|
|
linux toolchain all: outputmakefile
|
Makefile: unconfigured "make toolchain" should run report error
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>
2017-06-30 19:00:33 +02:00
|
|
|
$(error Please configure Buildroot first (e.g. "make menuconfig"))
|
|
|
|
|
@exit 1
|
|
|
|
|
|
2013-02-05 08:16:02 +01:00
|
|
|
endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
|
|
|
|
|
|
2004-10-09 03:06:03 +02:00
|
|
|
# configuration
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2014-04-23 10:39:23 +02:00
|
|
|
HOSTCFLAGS = $(CFLAGS_FOR_BUILD)
|
2007-07-09 20:23:20 +02:00
|
|
|
export HOSTCFLAGS
|
|
|
|
|
|
2010-06-20 23:05:32 +02:00
|
|
|
$(BUILD_DIR)/buildroot-config/%onf:
|
|
|
|
|
mkdir -p $(@D)/lxdialog
|
2015-01-03 00:58:47 +01:00
|
|
|
PKG_CONFIG_PATH="$(HOST_PKG_CONFIG_PATH)" $(MAKE) CC="$(HOSTCC_NOCCACHE)" HOSTCC="$(HOSTCC_NOCCACHE)" \
|
|
|
|
|
obj=$(@D) -C $(CONFIG) -f Makefile.br $(@F)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2013-02-05 08:16:02 +01:00
|
|
|
DEFCONFIG = $(call qstrip,$(BR2_DEFCONFIG))
|
|
|
|
|
|
|
|
|
|
# We don't want to fully expand BR2_DEFCONFIG here, so Kconfig will
|
|
|
|
|
# recognize that if it's still at its default $(CONFIG_DIR)/defconfig
|
Factorize environment variables for config utilities
Instead of duplicating the definition of KCONFIG_AUTOCONFIG,
KCONFIG_AUTOHEADER and BUILDROOT_CONFIG, let's define them in a
COMMON_CONFIG_ENV variable, which is used by all the xconfig, gconfig,
menuconfig, nconfig, config, oldconfig, randconfig, allyesconfig,
allnoconfig, randpackageconfig, allyespackageconfig,
allnopackageconfig, defconfig, %_defconfig targets.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-21 18:29:27 +02:00
|
|
|
COMMON_CONFIG_ENV = \
|
2013-02-05 08:16:02 +01:00
|
|
|
BR2_DEFCONFIG='$(call qstrip,$(value BR2_DEFCONFIG))' \
|
Factorize environment variables for config utilities
Instead of duplicating the definition of KCONFIG_AUTOCONFIG,
KCONFIG_AUTOHEADER and BUILDROOT_CONFIG, let's define them in a
COMMON_CONFIG_ENV variable, which is used by all the xconfig, gconfig,
menuconfig, nconfig, config, oldconfig, randconfig, allyesconfig,
allnoconfig, randpackageconfig, allyespackageconfig,
allnopackageconfig, defconfig, %_defconfig targets.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-21 18:29:27 +02:00
|
|
|
KCONFIG_AUTOCONFIG=$(BUILD_DIR)/buildroot-config/auto.conf \
|
|
|
|
|
KCONFIG_AUTOHEADER=$(BUILD_DIR)/buildroot-config/autoconf.h \
|
Ensure that all config-related files are generated before the build
The previous commit has removed calls to conf_write_autoconf(), which
is the function that generates the KCONFIG_AUTOCONF,
KCONFIG_AUTOHEADER, KCONFIG_TRISTATE files and the split config (with
one file per config item). Therefore, those things were not generated
anymore before the build.
In order to get them generated before the build, we use the same
mechanism as the kernel: run a silentoldconfig when the .config file
is newer than the KCONFIG_AUTOCONF file.
In Buildroot, all those elements are not really used today, except the
split config which is used a little bit in the toolchain build, in a
try to make sure the toolchain gets rebuilt properly when the
configuration changes. It does not seem that this work has been
completed.
However, as we want to keep the same behaviour as previously, we have
to generate all those elements before starting the build.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-22 07:27:09 +02:00
|
|
|
KCONFIG_TRISTATE=$(BUILD_DIR)/buildroot-config/tristate.config \
|
2014-02-04 16:18:52 +01:00
|
|
|
BR2_CONFIG=$(BR2_CONFIG) \
|
2015-12-31 01:34:13 +01:00
|
|
|
HOST_GCC_VERSION="$(HOSTCC_VERSION)" \
|
2019-07-29 22:19:53 +02:00
|
|
|
BASE_DIR=$(BASE_DIR) \
|
2015-04-11 01:49:02 +02:00
|
|
|
SKIP_LEGACY=
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
xconfig: $(BUILD_DIR)/buildroot-config/qconf outputmakefile
|
2010-11-24 15:30:54 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN)
|
2009-07-20 19:17:10 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
gconfig: $(BUILD_DIR)/buildroot-config/gconf outputmakefile
|
2010-11-24 15:30:54 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) srctree=$(TOPDIR) $< $(CONFIG_CONFIG_IN)
|
2010-06-05 21:09:05 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
menuconfig: $(BUILD_DIR)/buildroot-config/mconf outputmakefile
|
2010-11-24 15:30:54 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
nconfig: $(BUILD_DIR)/buildroot-config/nconf outputmakefile
|
2010-11-24 15:30:54 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
config: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
Factorize environment variables for config utilities
Instead of duplicating the definition of KCONFIG_AUTOCONFIG,
KCONFIG_AUTOHEADER and BUILDROOT_CONFIG, let's define them in a
COMMON_CONFIG_ENV variable, which is used by all the xconfig, gconfig,
menuconfig, nconfig, config, oldconfig, randconfig, allyesconfig,
allnoconfig, randpackageconfig, allyespackageconfig,
allnopackageconfig, defconfig, %_defconfig targets.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-08-21 18:29:27 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) $< $(CONFIG_CONFIG_IN)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2015-04-11 01:49:02 +02:00
|
|
|
# For the config targets that automatically select options, we pass
|
|
|
|
|
# SKIP_LEGACY=y to disable the legacy options. However, in that case
|
|
|
|
|
# no values are set for the legacy options so a subsequent oldconfig
|
|
|
|
|
# will query them. Therefore, run an additional olddefconfig.
|
|
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
randconfig allyesconfig alldefconfig allnoconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
2017-07-21 03:05:28 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) SKIP_LEGACY=y $< --$@ $(CONFIG_CONFIG_IN)
|
2015-04-11 01:49:02 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) $< --olddefconfig $(CONFIG_CONFIG_IN) >/dev/null
|
2009-10-04 21:57:12 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
randpackageconfig allyespackageconfig allnopackageconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
2014-02-04 16:18:52 +01:00
|
|
|
@grep -v BR2_PACKAGE_ $(BR2_CONFIG) > $(CONFIG_DIR)/.config.nopkg
|
2015-04-11 01:49:02 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) SKIP_LEGACY=y \
|
2010-01-11 13:28:50 +01:00
|
|
|
KCONFIG_ALLCONFIG=$(CONFIG_DIR)/.config.nopkg \
|
2017-07-21 03:05:28 +02:00
|
|
|
$< --$(subst package,,$@) $(CONFIG_CONFIG_IN)
|
2010-01-11 13:28:50 +01:00
|
|
|
@rm -f $(CONFIG_DIR)/.config.nopkg
|
2015-04-11 01:49:02 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) $< --olddefconfig $(CONFIG_CONFIG_IN) >/dev/null
|
2009-10-04 21:57:12 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
oldconfig syncconfig olddefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
2017-07-21 03:05:28 +02:00
|
|
|
@$(COMMON_CONFIG_ENV) $< --$@ $(CONFIG_CONFIG_IN)
|
2013-04-04 13:24:25 +02:00
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
2013-02-05 08:16:02 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) $< --defconfig$(if $(DEFCONFIG),=$(DEFCONFIG)) $(CONFIG_CONFIG_IN)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
Makefile: fix use of many br2-external trees
The top level Makefile in buildroot has a recursive rule which causes
the appearance of a hang as the number of directories in BR2_EXTERNAL
increases. When the number of directories in BR2_EXTERNAL is small, the
recursion occurs, but make detects the recursion and determines the
target does not have to be remade. This allows make to progress.
This is the failing rule:
define percent_defconfig
# Override the BR2_DEFCONFIG from COMMON_CONFIG_ENV with the new defconfig
%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(1)/configs/%_defconfig outputmakefile
@$$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(1)/configs/$$@ \
$$< --defconfig=$(1)/configs/$$@ $$(CONFIG_CONFIG_IN)
endef
$(eval $(foreach d,$(call reverse,$(TOPDIR) $(BR2_EXTERNAL_DIRS)),$(call percent_defconfig,$(d))$(sep)))
The rule for %defconfig is created for each directory in BR2_EXTERNAL.
When the rule is matched, the stem is 'defconfig_name'. The second
prerequisite is expanded to $(1)/configs/defconfig_name_defconfig. The
rule, and all of the other rules defined by this macro, are invoked
again, but the stem is now $(1)/configs/defconfig_name_defconfig. The
second prerequisite is now expanded to
$(1)/configs/($1)/configs/defconfig_name_defconfig. This expansion
continues until make detects the infinite recursion.
With up to 5 br2-external trees, the time is very small, so that it is
not noticeable. But starting with 6 br2-external trees, the time is
insanely big (so much so that we did not even let it finish after it ran
for hours); see timings toward the end of the commit log.
We fix that by adding a single %_defconfig rule, which is now rsponsible
to find the actual defconfig file that triggered the rule, by iterating
on the reverse list of br2-external trees and then in main tree.
Of course, now, there is no way for make to warn that there is no such
defconfig, as it is no longer part of the prerequisites of the rule. So,
we delegate to the recipe the responsibility to check for that.
Timing (seconds) of `make pc_x86_64_bios_defconfig` with 1..1000
external trees, with make 4.2.1 (* with make 4.3), on a Core i7-7700HQ:
#trees Before After
1 0.312 0.319
2 0.319 0.323
3 0.325 0.327
4 0.353 0.339
5 0.993 0.349
6 1.26* 0.347
7 9.10* 0.362
8 85.93* 0.360
9 n/a 0.373
10 n/a 0.374
50 n/a 0.738
100 n/a 1.228
500 n/a 7.483
1000 n/a 16.076
How to reproduce:
#!/usr/bin/env bash
N="${1:-1000}"
for i in $(seq 1 1000); do
[ -d "br2-external/${i}/configs" ] && break
mkdir -p br2-external/${i}/configs
touch br2-external/${i}/{Config.in,external.mk}
echo "name: BR_TEST_${i}" >br2-external/${i}/external.desc
touch br2-external/${i}/configs/foo{,_${i}}_defconfig
done
time make \
BR2_EXTERNAL="$(
for i in $(seq 1 ${N}); do
printf '%s\n' "$(pwd)/br2-external/${i}"
done
)" \
foo_1_defconfig
Notes: the timings are very dependent on how much the CPU is otherwise
loaded, but having a multi-core CPU slightly loaded helps maintain a
high frequency on the siblings, and that can reduce the above timings
in half! Best to try on an otherwise-idle system.
Fixes: #14996
Reported-by: David Lawson <david.lawson1@tx.rr.com>
Signed-off-by: Nevo Hed <nhed+buildroot@starry.com>
[yann.morin.1998@free.fr:
- split long foreach
- drastically extend the commit log
- provide reproducer script and redo timings
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2023-01-05 02:57:59 +01:00
|
|
|
%_defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
|
|
|
|
@defconfig=$(or \
|
|
|
|
|
$(firstword \
|
|
|
|
|
$(foreach d, \
|
|
|
|
|
$(call reverse,$(TOPDIR) $(BR2_EXTERNAL_DIRS)), \
|
|
|
|
|
$(wildcard $(d)/configs/$@) \
|
|
|
|
|
) \
|
|
|
|
|
), \
|
|
|
|
|
$(error "Can't find $@") \
|
|
|
|
|
); \
|
|
|
|
|
$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$${defconfig} \
|
|
|
|
|
$< --defconfig=$${defconfig} $(CONFIG_CONFIG_IN)
|
2013-12-05 20:11:12 +01:00
|
|
|
|
2019-01-26 01:34:06 +01:00
|
|
|
update-defconfig: savedefconfig
|
|
|
|
|
|
2019-07-29 22:19:57 +02:00
|
|
|
savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
|
2013-02-05 08:16:02 +01:00
|
|
|
@$(COMMON_CONFIG_ENV) $< \
|
|
|
|
|
--savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
|
|
|
|
|
$(CONFIG_CONFIG_IN)
|
Revert "Makefile: exclude BR2_DL_DIR from savedefconfig"
Although BR2_DL_DIR is indeed a site-local setting, which does not
actually define the target system, we've had it in the tree for a
long time now, and people have been depending on it for a variety
of use-cases.
Furthermore, BR2_DL_DIR is far from the only such site-local setting,
BR2_CCACHE_DIR springs to mind, and in the less-obvious category, we
can also find BR2_JLEVEL, but also BR2_WGET, BR2_SVN, BR2_GIT et al.
as they may be tweaked to set the timeout, number of retries or so on
to work around stupid proxies. But of course, the most local site-local
setting is probably BR2_PACKAGE_OVERRIDE_FILE, with its default value
being explicitly just 'local.mk'.
Ideally, we would like to have a clear separation between the
configuration that actually defines the target system on one hand,
and the site-local settings that drive and control how the build is
performed, on the other hand. This is by far a much bigger endeavour
than just dropping BR2_DL_DIR from the saved defconfig.
This reverts commit 36edacce9c2c3b90f9bb11a5d2208e8edf7bbe63 (adapted
to keep the fix from 1a7873ec986c817fdd22cc2d9096d9482fee4381).
Closes: #13291
Note: thanks to Thomas; some phrasing above was borrowed from a
discussion with him.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Lance Fredrickson <lancethepants@gmail.com>
Cc: Sven Oliver Moll <buildroot@svol.li>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Adam Duskett <aduskett@gmail.com>
2020-11-06 19:26:41 +01:00
|
|
|
@$(SED) '/^BR2_DEFCONFIG=/d' $(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig)
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2019-01-26 01:34:06 +01:00
|
|
|
.PHONY: defconfig savedefconfig update-defconfig
|
2009-11-20 14:05:48 +01:00
|
|
|
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2004-10-09 03:06:03 +02:00
|
|
|
#
|
|
|
|
|
# Cleanup and misc junk
|
|
|
|
|
#
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2010-09-26 10:56:12 +02:00
|
|
|
|
Makefile: move mkdir rule to after HOST_DIR is defined
HOST_DIR is defined twice: once to its default value before .config is
included, and once more to BR2_HOST_DIR after .config is included.
However, the rule that defines the mkdir for HOST_DIR comes between
these two, so it will always use the default definition. Therefore,
if a non-default BR2_HOST_DIR is used, there will be no rule to create
that directory, while the dirs target depends on it.
This happens to work at the moment, because in the dirs target,
$(STAGING_DIR) comes before $(HOST_DIR), so $(HOST_DIR) will be created
implicitly. However, this will fail in top-level parallel builds where
both will be created in parallel.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2017-08-04 18:31:29 +02:00
|
|
|
# staging and target directories do NOT list these as
|
|
|
|
|
# dependencies anywhere else
|
Makefile: fix build when $(O) ends in _defconfig
Commit e6195c53041f (Makefile: fix use of many br2-external trees) fixed
a slowdown with many br2-external trees. In doing so, it changed the
type of the %_defconfig rule: the stem is no longer present in the
prerequisites, so it changes from a pattern rule to an implicit pattern
rule [0].
It is not unusual to name the build directory after the defconfig that
is being built, so we may end up with a build directory named
meh_defconfig. Before e6195c53041f, the pattern rule would not match
[1], but now it does, which causes somewhat-cryptic build failures:
Makefile:1015: *** "Can't find /some/path/meh_defconfig". Stop.
The issue is that we have this set of rules and assignments (elided and
reordered for legibility):
all: world
world: target-post-image
target-post-image: staging-finalize
staging-finalize: $(STAGING_DIR_SYMLINK)
$(STAGING_DIR_SYMLINK): | $(BASE_DIR)
BASE_DIR := $(CANONICAL_O)
CANONICAL_O := $(shell mkdir -p $(O) >/dev/null 2>&1)$(realpath $(O))
So, there is a rule that (eventually) has a dependency on $(O), but we
have no rule that provides it explicitly, so the %_defconfig rule kicks
in, with the stem as "/some/path/meh". When the loop searches all the
".../configs/" directories for a file named ".../configs/%_defconfig",
it actually looks for a file named ".../configs//some/path/meh_defconfig"
and that indeed never matches anything.
The solution is to provide an actual rule for $(BASE_DIR), so that the
implicit rule does not kick in.
[0] Terminology and behaviour in make is hard, so the terms we used here
may be wrong or incorrectly used, and/or the explanations for the
behaviour be wrong or incomplete... Still, the reasoning stands, and
the root cause is the removal of the stem in the RHS of the rule
(adding one back does fix the issue).
[1] not sure how the prerequisite was solved before e6195c53041f,
though...
Fixes: e6195c53041f
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Nevo Hed <nhed+buildroot@starry.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Tested-by: Sebastian Weyer <sebastian.weyer@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2023-01-22 10:09:47 +01:00
|
|
|
$(BASE_DIR) $(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST) $(PER_PACKAGE_DIR):
|
Makefile: move mkdir rule to after HOST_DIR is defined
HOST_DIR is defined twice: once to its default value before .config is
included, and once more to BR2_HOST_DIR after .config is included.
However, the rule that defines the mkdir for HOST_DIR comes between
these two, so it will always use the default definition. Therefore,
if a non-default BR2_HOST_DIR is used, there will be no rule to create
that directory, while the dirs target depends on it.
This happens to work at the moment, because in the dirs target,
$(STAGING_DIR) comes before $(HOST_DIR), so $(HOST_DIR) will be created
implicitly. However, this will fail in top-level parallel builds where
both will be created in parallel.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2017-08-04 18:31:29 +02:00
|
|
|
@mkdir -p $@
|
|
|
|
|
|
2010-09-26 10:56:12 +02:00
|
|
|
# outputmakefile generates a Makefile in the output directory, if using a
|
|
|
|
|
# separate output directory. This allows convenient use of make in the
|
|
|
|
|
# output directory.
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: outputmakefile
|
2010-09-26 10:56:12 +02:00
|
|
|
outputmakefile:
|
|
|
|
|
ifeq ($(NEED_WRAPPER),y)
|
2011-08-31 23:35:02 +02:00
|
|
|
$(Q)$(TOPDIR)/support/scripts/mkmakefile $(TOPDIR) $(O)
|
2010-09-26 10:56:12 +02:00
|
|
|
endif
|
|
|
|
|
|
2015-11-04 22:42:39 +01:00
|
|
|
# printvars prints all the variables currently defined in our
|
|
|
|
|
# Makefiles. Alternatively, if a non-empty VARS variable is passed,
|
|
|
|
|
# only the variables matching the make pattern passed in VARS are
|
|
|
|
|
# displayed.
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
# show-vars does the same, but as a JSON dictionnary.
|
2022-07-29 23:49:33 +02:00
|
|
|
#
|
|
|
|
|
# Note: we iterate of .VARIABLES and filter each variable individually,
|
|
|
|
|
# to workaround a bug in make 4.3; see https://savannah.gnu.org/bugs/?59093
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: printvars
|
2022-07-29 23:49:33 +02:00
|
|
|
printvars:
|
2022-08-02 14:35:59 +02:00
|
|
|
ifndef VARS
|
2022-08-04 23:05:01 +02:00
|
|
|
$(error Please pass a non-empty VARS to 'make printvars')
|
2022-08-02 14:35:59 +02:00
|
|
|
endif
|
Makefile: fix issue with printvars executing giant shell command
The underlying problem is that $(foreach V,1 2 3,) does not evaluate to
an empty string. It evaluates to " ", three empty strings separated by
whitespace.
A construct of this format, with a giant list in the foreach, is part of
the printvars command. This means that "@:$(foreach ....)", which is
intended to expand to a null command, in fact expands to "@: "
with a great deal of whitespace. Make chooses to execute this command
with:
execve("/bin/sh", ["/bin/sh", "-c", ": "]
But with far more whitespace. So much that it can exceed shell command
line length limits.
This solution is to move the foreach to another step in the recipe. The
"@:" is retained as the first line so the recipe is not Empty, which
would cause a change in make behavior when make builds the target. The
2nd line, all whitespace, will be skipped by make.
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Tested-by: "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>
2018-09-17 20:10:54 +02:00
|
|
|
@:
|
|
|
|
|
$(foreach V, \
|
2022-07-29 23:49:33 +02:00
|
|
|
$(sort $(foreach X, $(.VARIABLES), $(filter $(VARS),$(X)))), \
|
2013-05-29 00:41:11 +02:00
|
|
|
$(if $(filter-out environment% default automatic, \
|
|
|
|
|
$(origin $V)), \
|
core: enhance printvars
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>
2017-03-29 11:43:05 +02:00
|
|
|
$(if $(QUOTED_VARS),\
|
|
|
|
|
$(info $V='$(subst ','\'',$(if $(RAW_VARS),$(value $V),$($V)))'), \
|
|
|
|
|
$(info $V=$(if $(RAW_VARS),$(value $V),$($V))))))
|
2021-11-13 14:28:18 +01:00
|
|
|
# ')))) # Syntax colouring...
|
2013-05-29 00:41:11 +02:00
|
|
|
|
2022-07-29 23:49:33 +02:00
|
|
|
# See details above, same as for printvars
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
.PHONY: show-vars
|
|
|
|
|
show-vars: VARS?=%
|
2022-07-29 23:49:33 +02:00
|
|
|
show-vars:
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
@:
|
Makefile: fix show-vars for good this time
Commit 5c54c3ef3db2 (Makefile: workaround make 4.3 issue for 'printvars
and 'show-vars') did not fully fix the show-vars case, which still
segfaults.
Overall, show-vars generates a JSON blurb. That is supposed to be
machine-readable, so we do not care that the variables are sorted, so
we get rid of it to (slightly) simplify the code.
Then, we currently iterate twice on the list of variables: the first one
to filter-out the 'internal' variables, and the second one to filter
only the variables matching the pattern. We can do away by iterating
only once, and applying both filters at once.
Since we now have an 'and' condition, we can take advantage of it: when
none of the items in $(and) are empty, $(and) evaluates to the last
item, while it evaluates to empty if any of the items is empty. So we
can coalesce the $(if) and $(and) together: $(if $(and a,b),c) is
equivalent to: $(and a,b,c) ; this gains us one parentheses depth.
Finally, the cause for the segfault is an overly-long call to $(info).
Reducing that is not easy: we want to call clean-json on the whole of
the JSON blurb, so we can't emit the individual variables one by one, or
the trailing comma would not be trimmed away.
So, we go crazy: we just output each word from clean-json with $(info).
We can do that, because mk-json-str transforms all spaces in a string
to an escaped UTF-8 sequence, so we will never have spaces in values;
the keys are the variables, so they won't have spaces either; spaces in
the rest of the JSON blurb are totally optional, so we don't care how
many there are. We know there are spaces, because we explicitly
introduce some (after "expanded" or "raw", for example), so we should
never hit a too-big word for $(info) to print.
Thanks to Henri for the suggestion to push $(info) further inside the
macro.
Reported-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Roosen Henri <Henri.Roosen@ginzinger.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-01 22:42:27 +02:00
|
|
|
$(foreach i, \
|
|
|
|
|
$(call clean-json, { \
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
$(foreach V, \
|
Makefile: fix show-vars for good this time
Commit 5c54c3ef3db2 (Makefile: workaround make 4.3 issue for 'printvars
and 'show-vars') did not fully fix the show-vars case, which still
segfaults.
Overall, show-vars generates a JSON blurb. That is supposed to be
machine-readable, so we do not care that the variables are sorted, so
we get rid of it to (slightly) simplify the code.
Then, we currently iterate twice on the list of variables: the first one
to filter-out the 'internal' variables, and the second one to filter
only the variables matching the pattern. We can do away by iterating
only once, and applying both filters at once.
Since we now have an 'and' condition, we can take advantage of it: when
none of the items in $(and) are empty, $(and) evaluates to the last
item, while it evaluates to empty if any of the items is empty. So we
can coalesce the $(if) and $(and) together: $(if $(and a,b),c) is
equivalent to: $(and a,b,c) ; this gains us one parentheses depth.
Finally, the cause for the segfault is an overly-long call to $(info).
Reducing that is not easy: we want to call clean-json on the whole of
the JSON blurb, so we can't emit the individual variables one by one, or
the trailing comma would not be trimmed away.
So, we go crazy: we just output each word from clean-json with $(info).
We can do that, because mk-json-str transforms all spaces in a string
to an escaped UTF-8 sequence, so we will never have spaces in values;
the keys are the variables, so they won't have spaces either; spaces in
the rest of the JSON blurb are totally optional, so we don't care how
many there are. We know there are spaces, because we explicitly
introduce some (after "expanded" or "raw", for example), so we should
never hit a too-big word for $(info) to print.
Thanks to Henri for the suggestion to push $(info) further inside the
macro.
Reported-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Roosen Henri <Henri.Roosen@ginzinger.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-01 22:42:27 +02:00
|
|
|
$(.VARIABLES), \
|
|
|
|
|
$(and $(filter $(VARS),$(V)) \
|
|
|
|
|
, \
|
|
|
|
|
$(filter-out environment% default automatic, $(origin $V)) \
|
|
|
|
|
, \
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
"$V": { \
|
|
|
|
|
"expanded": $(call mk-json-str,$($V))$(comma) \
|
|
|
|
|
"raw": $(call mk-json-str,$(value $V)) \
|
|
|
|
|
}$(comma) \
|
|
|
|
|
) \
|
|
|
|
|
) \
|
Makefile: fix show-vars for good this time
Commit 5c54c3ef3db2 (Makefile: workaround make 4.3 issue for 'printvars
and 'show-vars') did not fully fix the show-vars case, which still
segfaults.
Overall, show-vars generates a JSON blurb. That is supposed to be
machine-readable, so we do not care that the variables are sorted, so
we get rid of it to (slightly) simplify the code.
Then, we currently iterate twice on the list of variables: the first one
to filter-out the 'internal' variables, and the second one to filter
only the variables matching the pattern. We can do away by iterating
only once, and applying both filters at once.
Since we now have an 'and' condition, we can take advantage of it: when
none of the items in $(and) are empty, $(and) evaluates to the last
item, while it evaluates to empty if any of the items is empty. So we
can coalesce the $(if) and $(and) together: $(if $(and a,b),c) is
equivalent to: $(and a,b,c) ; this gains us one parentheses depth.
Finally, the cause for the segfault is an overly-long call to $(info).
Reducing that is not easy: we want to call clean-json on the whole of
the JSON blurb, so we can't emit the individual variables one by one, or
the trailing comma would not be trimmed away.
So, we go crazy: we just output each word from clean-json with $(info).
We can do that, because mk-json-str transforms all spaces in a string
to an escaped UTF-8 sequence, so we will never have spaces in values;
the keys are the variables, so they won't have spaces either; spaces in
the rest of the JSON blurb are totally optional, so we don't care how
many there are. We know there are spaces, because we explicitly
introduce some (after "expanded" or "raw", for example), so we should
never hit a too-big word for $(info) to print.
Thanks to Henri for the suggestion to push $(info) further inside the
macro.
Reported-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Roosen Henri <Henri.Roosen@ginzinger.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-08-01 22:42:27 +02:00
|
|
|
} ) \
|
|
|
|
|
, \
|
|
|
|
|
$(info $(i)) \
|
|
|
|
|
)
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: clean
|
2004-10-09 03:06:03 +02:00
|
|
|
clean:
|
2018-03-31 11:05:50 +02:00
|
|
|
rm -rf $(BASE_TARGET_DIR) $(BINARIES_DIR) $(HOST_DIR) $(HOST_DIR_SYMLINK) \
|
2014-03-17 09:22:33 +01:00
|
|
|
$(BUILD_DIR) $(BASE_DIR)/staging \
|
2023-10-02 05:57:32 +02:00
|
|
|
$(LEGAL_INFO_DIR) $(GRAPHS_DIR) $(PER_PACKAGE_DIR) $(O)/pkg-stats.*
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: distclean
|
2004-10-09 03:06:03 +02:00
|
|
|
distclean: clean
|
2016-11-23 03:23:02 +01:00
|
|
|
ifeq ($(O),$(CURDIR)/output)
|
2009-11-20 14:05:48 +01:00
|
|
|
rm -rf $(O)
|
|
|
|
|
endif
|
2016-09-11 15:55:46 +02:00
|
|
|
rm -rf $(TOPDIR)/dl $(BR2_CONFIG) $(CONFIG_DIR)/.config.old $(CONFIG_DIR)/..config.tmp \
|
2019-07-29 22:19:55 +02:00
|
|
|
$(CONFIG_DIR)/.auto.deps $(BASE_DIR)/.br2-external.*
|
2004-10-09 03:06:03 +02:00
|
|
|
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: help
|
2016-04-16 23:20:17 +02:00
|
|
|
help:
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo 'Cleaning:'
|
2009-11-20 14:05:48 +01:00
|
|
|
@echo ' clean - delete all files created by build'
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo ' distclean - delete all non-source files (including .config)'
|
|
|
|
|
@echo
|
|
|
|
|
@echo 'Build:'
|
|
|
|
|
@echo ' all - make world'
|
2013-01-14 23:02:00 +01:00
|
|
|
@echo ' toolchain - build toolchain'
|
2017-07-22 13:15:40 +02:00
|
|
|
@echo ' sdk - build relocatable SDK'
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo
|
|
|
|
|
@echo 'Configuration:'
|
|
|
|
|
@echo ' menuconfig - interactive curses-based configurator'
|
2011-02-01 08:41:01 +01:00
|
|
|
@echo ' nconfig - interactive ncurses-based configurator'
|
2009-10-04 21:42:54 +02:00
|
|
|
@echo ' xconfig - interactive Qt-based configurator'
|
2010-06-05 21:09:05 +02:00
|
|
|
@echo ' gconfig - interactive GTK-based configurator'
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo ' oldconfig - resolve any unresolved symbols in .config'
|
2018-09-19 13:36:15 +02:00
|
|
|
@echo ' syncconfig - Same as oldconfig, but quietly, additionally update deps'
|
|
|
|
|
@echo ' olddefconfig - Same as syncconfig but sets new symbols to their default value'
|
2009-10-04 21:42:54 +02:00
|
|
|
@echo ' randconfig - New config with random answer to all options'
|
2018-07-22 23:34:45 +02:00
|
|
|
@echo ' defconfig - New config with default answer to all options;'
|
|
|
|
|
@echo ' BR2_DEFCONFIG, if set on the command line, is used as input'
|
2015-02-11 14:14:49 +01:00
|
|
|
@echo ' savedefconfig - Save current config to BR2_DEFCONFIG (minimal config)'
|
2019-01-26 01:34:06 +01:00
|
|
|
@echo ' update-defconfig - Same as savedefconfig'
|
2009-10-04 21:42:54 +02:00
|
|
|
@echo ' allyesconfig - New config where all options are accepted with yes'
|
|
|
|
|
@echo ' allnoconfig - New config where all options are answered with no'
|
2017-07-21 03:05:29 +02:00
|
|
|
@echo ' alldefconfig - New config where all options are set to default'
|
2009-10-04 21:57:12 +02:00
|
|
|
@echo ' randpackageconfig - New config with random answer to package options'
|
|
|
|
|
@echo ' allyespackageconfig - New config where pkg options are accepted with yes'
|
|
|
|
|
@echo ' allnopackageconfig - New config where package options are answered with no'
|
2015-03-21 20:49:47 +01:00
|
|
|
@echo
|
|
|
|
|
@echo 'Package-specific:'
|
|
|
|
|
@echo ' <pkg> - Build and install <pkg> and all its dependencies'
|
|
|
|
|
@echo ' <pkg>-source - Only download the source files for <pkg>'
|
|
|
|
|
@echo ' <pkg>-extract - Extract <pkg> sources'
|
|
|
|
|
@echo ' <pkg>-patch - Apply patches to <pkg>'
|
|
|
|
|
@echo ' <pkg>-depends - Build <pkg>'\''s dependencies'
|
|
|
|
|
@echo ' <pkg>-configure - Build <pkg> up to the configure step'
|
|
|
|
|
@echo ' <pkg>-build - Build <pkg> up to the build step'
|
core: add per-package and per-filesystem show-info
Sometimes, it is need to quickly get the metadata of a subset of
packages, without resorting to a full-blown JSON query.
Introduce a new per-package (and per-filesystem) foo-show-info rule,
that otputs a per-entity valid JSON blob.
Note that calling it for multiple packages and.or filesystems at once
will not generate a valid JSON blob, as there would be no separator
between the JSON elements:
$ make {foo,bar}-show-info
{ "foo": { foo stuff } }
{ "bar": { bar stuff } }
However, jq is able to absorb this, with its slurping ability, which
generates an array (ellipsed and manualy reformated for readability):
$ make {foo,bar}-show-info |jq -s . -
[
{ "foo": { foo stuff } },
{ "bar": { bar stuff } }
]
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: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-15 21:47:32 +02:00
|
|
|
@echo ' <pkg>-show-info - generate info about <pkg>, as a JSON blurb'
|
2016-10-23 17:28:51 +02:00
|
|
|
@echo ' <pkg>-show-depends - List packages on which <pkg> depends'
|
|
|
|
|
@echo ' <pkg>-show-rdepends - List packages which have <pkg> as a dependency'
|
2018-03-31 18:35:43 +02:00
|
|
|
@echo ' <pkg>-show-recursive-depends'
|
|
|
|
|
@echo ' - Recursively list packages on which <pkg> depends'
|
|
|
|
|
@echo ' <pkg>-show-recursive-rdepends'
|
|
|
|
|
@echo ' - Recursively list packages which have <pkg> as a dependency'
|
2015-03-21 20:49:47 +01:00
|
|
|
@echo ' <pkg>-graph-depends - Generate a graph of <pkg>'\''s dependencies'
|
2016-10-23 19:19:44 +02:00
|
|
|
@echo ' <pkg>-graph-rdepends - Generate a graph of <pkg>'\''s reverse dependencies'
|
2015-03-21 20:49:47 +01:00
|
|
|
@echo ' <pkg>-dirclean - Remove <pkg> build directory'
|
|
|
|
|
@echo ' <pkg>-reconfigure - Restart the build from the configure step'
|
|
|
|
|
@echo ' <pkg>-rebuild - Restart the build from the build step'
|
2021-07-03 21:40:00 +02:00
|
|
|
@echo ' <pkg>-reinstall - Restart the build from the install step'
|
2016-06-04 18:30:48 +02:00
|
|
|
$(foreach p,$(HELP_PACKAGES), \
|
|
|
|
|
@echo $(sep) \
|
|
|
|
|
@echo '$($(p)_NAME):' $(sep) \
|
|
|
|
|
$($(p)_HELP_CMDS)$(sep))
|
2011-10-10 10:46:40 +02:00
|
|
|
@echo
|
|
|
|
|
@echo 'Documentation:'
|
2013-09-19 12:47:14 +02:00
|
|
|
@echo ' manual - build manual in all formats'
|
2011-10-10 10:46:40 +02:00
|
|
|
@echo ' manual-html - build manual in HTML'
|
|
|
|
|
@echo ' manual-split-html - build manual in split HTML'
|
|
|
|
|
@echo ' manual-pdf - build manual in PDF'
|
2013-10-18 22:31:26 +02:00
|
|
|
@echo ' manual-text - build manual in text'
|
2011-10-10 10:46:40 +02:00
|
|
|
@echo ' manual-epub - build manual in ePub'
|
2013-12-28 18:39:11 +01:00
|
|
|
@echo ' graph-build - generate graphs of the build times'
|
2013-12-28 18:39:12 +01:00
|
|
|
@echo ' graph-depends - generate graph of the dependency tree'
|
2015-10-17 15:33:44 +02:00
|
|
|
@echo ' graph-size - generate stats of the filesystem size'
|
2015-04-23 23:04:06 +02:00
|
|
|
@echo ' list-defconfigs - list all defconfigs (pre-configured minimal systems)'
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo
|
|
|
|
|
@echo 'Miscellaneous:'
|
|
|
|
|
@echo ' source - download all sources needed for offline-build'
|
2008-03-04 13:19:16 +01:00
|
|
|
@echo ' external-deps - list external packages used'
|
2012-05-17 19:33:00 +02:00
|
|
|
@echo ' legal-info - generate info about license compliance'
|
core: introduce new global show-info
Users are increasingly trying to extract information about packages. For
example, they might need to get the list of URIs, or the dependencies of
a package.
Although we do have a bunch of rules to generate some of that, this is
done in ad-hoc way, with most of the output formats just ad-hoc, raw,
unformatted blurbs, mostly internal data dumped as-is.
Introduce a new rule, show-info, that provides a properly formatted
output of all the meta-information about packages: name, type, version,
licenses, dependencies...
We choose to use JSON as the output format, because it is pretty
versatile, has parsers in virtually all languages, has tools to parse
from the shell (jq). It also closely matches Python data structure,
which makes it easy to use with our own internal tools as well. Finally,
JSON being a key-value store, allows for easy expanding the output
without requiring existing consumers to be updated; new, unknown keys
are simply ignored by those (as long as they are true JSON parsers).
The complex part of this change was the conditional output of parts of
the data: virtual packages have no source, version, license or
downloads, unlike non-virtual packages. Same goes for filesystems. We
use a wrapper macro, show-info, that de-multiplexes unto either the
package-related- or filesystem-related macros, and for packages, we also
use a detailed macro for non-virtual packages.
It is non-trivial to properly output correct JSON blurbs, especially
when trying to output an array of objects, like so, where the last item
shall not be followed by a comma: [ { ... }, { ... } ]
So, we use a trick (as sugegsted by Arnout), to $(subst) any pair of
",}" or ", }" or ",]" or ", ]" with only the respective closing symbol,
"}" or "]".
The whole stuff is $(strip)ed to make it a somewhat-minified JSON blurb
that fits on a single line with all spaces squashed (but still with
spaces, as it is not possible to differentiate spaces between JSON
elements from spaces inside JSON strings).
Reported-by: Thomas De Schampheleire <patrickdepinguin@gmail.com>
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: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-04-15 21:47:31 +02:00
|
|
|
@echo ' show-info - generate info about packages, as a JSON blurb'
|
2020-11-05 17:30:22 +01:00
|
|
|
@echo ' pkg-stats - generate info about packages as JSON and HTML'
|
2019-03-12 18:55:34 +01:00
|
|
|
@echo ' printvars - dump internal variables selected with VARS=...'
|
Makefile: introduce show-vars, a json-formatted equivalent to printvars
The current printvars output suffers from a serious design flaw:
variables are not delimited, which makes it impossible to reliably
retrieve the value of variables; only variables that are known to
not contain a \n can be relatively safely extracted.
However, in some cases, it is important to be able to retrieve the
multi-line value of a variable, notably the CMDS or the hooks. One
such use-case (to follow in an unscheduled future) would be to hash
the variables that make up a package "configuration", and cache or
extract the files for that package to speed up the build.
Modeled after printvars and show-info, we introduce show-vars (what a
lack of imagination here) that outputs a json dictionary which keys are
the variable names, and for each variable, provides the raw and expanded
values.
Unlike printvars, we do not provide a way to get either the raw or
expanded value; both are systematically printed; a user will get just
the one is needs. Additionally, strings in JSON are quoted, so there is
no need to provide a way to quote variables; that would not make sense.
Note: for printvars, we require that the user provides an explicit
pattern to filter variables on. This is historical (see fd5bd12379dc,
Makefile: printvars: don't print anything when VARS is not set). The
underlying reasoning was that printvars is too "raw", and variables are
not well delimited, so printvars was mostly used to extract a few values
here and there, from scripts, or to quickly inspect a specific package's
variables during debugging.
But show-vars, although technically plain-text, being JSON, is not very
human-readable, and is mostly aimed at tools that will parse it with a
real JSON parser, and which will want to have a complete view of a lot
of variables at once. As such, and contrary to printvars, it makes sense
to report on all variables by default, unless the user explicitly
requested a subset.
As a final note: a lot of our variables only make sense in the context
of an actual make target. For example, a variable of package foo, that
contains $(@D)/bar, would expand to .../build/FOO-VERSION/bar. This is
because our CMDS and hooks are expanded as the recipe of a stamp file
that lies in the package build directory.
But for show-info, this falls flat on its face: it is not the stamp file
of a package, so there is no package directory, and show-info itself has
not directory part, so $(@D) expands to '.' (dot).
Additionally, some variables may contain calls to $(shell) (e.g. to call
pkg-config), and this also does not work with show-info.
These two issues make it impossible to emit the correct expanded value
of variables. To be noted: printvars has the exact same limitations for
the exact same reasons.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-11-13 14:28:27 +01:00
|
|
|
@echo ' show-vars - dump all internal variables as a JSON blurb; use VARS=...'
|
|
|
|
|
@echo ' to limit the list to variables names matching that pattern'
|
2007-07-08 14:20:58 +02:00
|
|
|
@echo
|
2011-02-01 08:41:01 +01:00
|
|
|
@echo ' make V=0|1 - 0 => quiet build (default), 1 => verbose build'
|
|
|
|
|
@echo ' make O=dir - Locate all output files in "dir", including .config'
|
|
|
|
|
@echo
|
2015-03-21 20:49:46 +01:00
|
|
|
@echo 'For further details, see README, generate the Buildroot manual, or consult'
|
|
|
|
|
@echo 'it on-line at http://buildroot.org/docs.html'
|
|
|
|
|
@echo
|
|
|
|
|
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
# List the defconfig files
|
|
|
|
|
# $(1): base directory
|
|
|
|
|
# $(2): br2-external name, empty for bundled
|
|
|
|
|
define list-defconfigs
|
|
|
|
|
@first=true; \
|
|
|
|
|
for defconfig in $(1)/configs/*_defconfig; do \
|
|
|
|
|
[ -f "$${defconfig}" ] || continue; \
|
|
|
|
|
if $${first}; then \
|
|
|
|
|
if [ "$(2)" ]; then \
|
2016-10-14 16:39:23 +02:00
|
|
|
printf 'External configs in "$(call qstrip,$(2))":\n'; \
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
else \
|
|
|
|
|
printf "Built-in configs:\n"; \
|
|
|
|
|
fi; \
|
|
|
|
|
first=false; \
|
|
|
|
|
fi; \
|
|
|
|
|
defconfig="$${defconfig##*/}"; \
|
|
|
|
|
printf " %-35s - Build for %s\n" "$${defconfig}" "$${defconfig%_defconfig}"; \
|
|
|
|
|
done; \
|
|
|
|
|
$${first} || printf "\n"
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# We iterate over BR2_EXTERNAL_NAMES rather than BR2_EXTERNAL_DIRS,
|
|
|
|
|
# because we want to display the name of the br2-external tree.
|
2017-06-15 00:11:31 +02:00
|
|
|
.PHONY: list-defconfigs
|
2015-03-21 20:49:46 +01:00
|
|
|
list-defconfigs:
|
core: add support for multiple br2-external trees
Currently, we only support at most one br2-external tree. Being able
to use more than one br2-external tree can be very useful.
A use-case would be for having a br2-external to contain the basic
packages, basic board defconfigs and board files, provided by one team
responsible for the "board-bringup", while other teams consume that
br2-external as a base, and complements it each with their own set of
packages, defconfigs and extra board files.
Another use-case would be for third-parties to provide their own
Buildroot packaging in a br2-external tree, along-side the archives for
their stuff.
Finally, another use-case is to be able to add FLOSS packages in a
br2-external tree, and proprietary packages in another. This allows
to not touch the Buildroot tree at all, and still be able to get in
compliance by providing only that br2-external tree(s) that contains
FLOSS packages, leaving aside the br2-external tree(s) with the
proprietary bits.
What we do is to treat BR2_EXTERNAL as a colon-separated (space-
separated also work, and we use that internally) list of paths, on which
we iterate to construct:
- the list of all br2-external names, BR2_EXTERNAL_NAMES,
- the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which
point each to the actual location of the corresponding tree,
- the list of paths to all the external.mk files, BR2_EXTERNAL_MKS,
- the space-separated list of absolute paths to the external trees,
BR2_EXTERNAL_DIRS.
Once we have all those variables, we replace references to BR2_EXTERNAL
with either one of those.
This cascades into how we display the list of defconfigs, so that it is
easy to see what br2-external tree provides what defconfigs. As
suggested by Arnout, tweak the comment from "User-provided configs" to
"External configs", on the assumption that some br2-external trees could
be provided by vendors, so not necessarily user-provided. Ditto the menu
in Kconfig, changed from "User-provided options" to "External options".
Now, when more than one br2-external tree is used, each gets its own
sub-menu in the "User-provided options" menu. The sub-menu is labelled
with that br2-external tree's name and the sub-menu's first item is a
comment with the path to that br2-external tree.
If there's only one br2-external tree, then there is no sub-menu; there
is a single comment that contains the name and path to the br2-external
tree.
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: Romain Naour <romain.naour@openwide.fr>
Cc: Julien CORJON <corjon.j@ecagroup.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-14 16:39:20 +02:00
|
|
|
$(call list-defconfigs,$(TOPDIR))
|
|
|
|
|
$(foreach name,$(BR2_EXTERNAL_NAMES),\
|
2016-10-14 16:39:23 +02:00
|
|
|
$(call list-defconfigs,$(BR2_EXTERNAL_$(name)_PATH),\
|
|
|
|
|
$(BR2_EXTERNAL_$(name)_DESC))$(sep))
|
2007-06-25 12:56:13 +02:00
|
|
|
|
2014-04-23 10:39:23 +02:00
|
|
|
release: OUT = buildroot-$(BR2_VERSION)
|
2010-11-04 00:00:00 +01:00
|
|
|
|
2012-02-03 22:03:29 +01:00
|
|
|
# Create release tarballs. We need to fiddle a bit to add the generated
|
|
|
|
|
# documentation to the git output
|
2010-11-04 00:00:00 +01:00
|
|
|
release:
|
2013-09-17 13:42:07 +02:00
|
|
|
git archive --format=tar --prefix=$(OUT)/ HEAD > $(OUT).tar
|
2013-10-18 22:31:26 +02:00
|
|
|
$(MAKE) O=$(OUT) manual-html manual-text manual-pdf
|
2020-05-08 10:32:20 +02:00
|
|
|
$(MAKE) O=$(OUT) distclean
|
2012-02-03 22:03:29 +01:00
|
|
|
tar rf $(OUT).tar $(OUT)
|
|
|
|
|
gzip -9 -c < $(OUT).tar > $(OUT).tar.gz
|
2021-12-02 18:01:45 +01:00
|
|
|
xz -9 -c < $(OUT).tar > $(OUT).tar.xz
|
2012-02-03 22:03:29 +01:00
|
|
|
rm -rf $(OUT) $(OUT).tar
|
2009-01-15 20:36:06 +01:00
|
|
|
|
2012-03-11 12:16:39 +01:00
|
|
|
print-version:
|
|
|
|
|
@echo $(BR2_VERSION_FULL)
|
|
|
|
|
|
2018-08-11 12:44:23 +02:00
|
|
|
check-package:
|
2023-02-06 22:10:57 +01:00
|
|
|
$(Q)./utils/check-package `git ls-tree -r --name-only HEAD` \
|
|
|
|
|
--ignore-list=$(TOPDIR)/.checkpackageignore
|
2018-08-11 12:44:23 +02:00
|
|
|
|
2022-07-31 21:35:10 +02:00
|
|
|
.PHONY: .checkpackageignore
|
|
|
|
|
.checkpackageignore:
|
Makefile: make check-package assume a git tree
... just like check-flake8 already does.
When a new check_function is added to check-package, often there are
files in the tree that would generate warnings.
An example is the Sob check_function for patch files:
| $ ./utils/check-package --i Sob $(git ls-files) >/dev/null
| 369301 lines processed
| 46 warnings generated
Currently these warnings are listed when calling check-package directly,
and also at the output of pkg-stats, but the check_function does not run
on 'make check-package' (that is used to catch regressions on GitLab CI
'check-package' job) until all warnings in the tree are fixed.
This (theoretically) allows new .patch files be added without SoB,
without the GitLab CI catching it.
Since now check-package has an ignore file to list all warnings in the
tree, that will eventually be fixed, there is no need to filter the
files passed to check-package.
So test all files in the tree when 'make check-package' is called.
It brings following advantages;
- any new check_function added to check-package takes place immediately
for new files;
- adding new check_functions is less traumatic to the developer doing
this, since he/she does not need anymore to fix all warnings in the
tree before the new check_function takes effect;
- prevent regressions, e.g. ANY new .patch file must have SoB;
- as a side-effect, print a single statistics line as output of
'make ckeck-package'.
But just enabling the check would generate many warnings when
'make check-package' is called, so update the ignore file by using:
$ ./utils/docker-run make .checkpackageignore
Notice: in order to ensure reproducible results, one should run 'make
check-package' and 'make .checkpackageignore' inside the docker image,
otherwise a variation in shellcheck version (installed in the host) can
produce different results.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-07-31 21:35:11 +02:00
|
|
|
$(Q)./utils/check-package --failed-only `git ls-tree -r --name-only HEAD` \
|
|
|
|
|
> .checkpackageignore
|
2022-07-31 21:35:10 +02:00
|
|
|
|
2012-04-17 16:45:22 +02:00
|
|
|
include docs/manual/manual.mk
|
2017-11-21 20:13:30 +01:00
|
|
|
-include $(foreach dir,$(BR2_EXTERNAL_DIRS),$(sort $(wildcard $(dir)/docs/*/*.mk)))
|
2011-10-10 10:46:40 +02:00
|
|
|
|
2009-10-04 21:57:12 +02:00
|
|
|
.PHONY: $(noconfig_targets)
|
2014-11-21 17:19:00 +01:00
|
|
|
|
package/pkg-generic.mk: fix rule order for reinstall/rebuild/reconfigure
The reinstall, rebuild and reconfigure commands rely on the
left-to-right order of evaluation of the dependencies to make sure that
the stamp files are removed before attempting to rebuild. However, this
order of evaluation is not guaranteed. In particular, if top-level
parallel build is enabled, they are executed in parallel and the stamp
file may not have been removed yet when it is evaluated to decide if
rebuild has to be done.
Since make 4.4, it is possible to reproduce this issue by passing
`--shuffle=reverse` to the make commandline.
To solve this, add a .WAIT directive between the clean and
install/build/configure dependencies. .WAIT was introduced in make 4.4
as well. It makes sure that the dependencies on the left are evaluated
before the dependencies on the right - exactly what we want here.
Earlier versions of make don't know about .WAIT, so we need to add a
.PHONY dependency to effectively ignore it.
Note that this doesn't fix the problem for make versions earlier than
4.4. However, the issue isn't really that important: reinstall, rebuild
and reconfigure are development tools, they're not fully reliable to
begin with, and it's anyway less likely that someone uses `make -j` when
doing a reinstall/rebuild/reconfigure.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Reported-by: James Hilliard <james.hilliard1@gmail.com>
2023-10-01 17:48:15 +02:00
|
|
|
# .WAIT was introduced in make 4.4. For older make, define it as phony.
|
|
|
|
|
.PHONY: .WAIT
|
|
|
|
|
|
core: re-enter make if $(CURDIR) or $(O) are not canonical paths
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be
resolved differently, depending on each package build-system (whether it
uses the given paths or get the absolute canonical ones).
Using absolute canonical paths will help achieving reproducible builds and
will make easier tracking down host machine paths leaking into the host,
target or staging trees.
So, this change ensures the build takes place with the CURDIR and O
variables are set to their absolute canonical paths.
In order to recall the toplevel makefile with absolute canonical paths
for $(CURDIR) and $(O), we need to:
1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will
be passed to the sub-make. This is achieved using the 'realpath' make
primitive. However, some care must be taken when manipulating O:
- the out-of-tree makefile wrapper happens a trailing "/.", we need
to strip this part away to not break the comparison driving the
sub-make call;
- the user can leave a trailing '/' to $(O);
- according to [1,2], realpath returns an empty string in case of
non-existing entry. So, to avoid passing an empty O= variable to
sub-make, it is necessary to define the output directory and create
it prior to call realpath on it (because on the first invocation,
$(O) usually does not yet exists), hence the trick doing the mkdir
right before calling realpath.
2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it
when call recalling the top-level makefile with umask and paths
correctly set.
3- Lastly, update the condition for setting the CONFIG_DIR and
NEED_WRAPPER variables.
Note:
* This change takes care of the makefile wrapper installed in $(O) to
avoid unneeded make recursion.
[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
[2] http://man7.org/linux/man-pages/man3/realpath.3.html
Reported-by: Matthew Weber <matt@thewebers.ws>
Cc: Matthew Weber <matt@thewebers.ws>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-17 23:05:43 +02:00
|
|
|
endif #umask / $(CURDIR) / $(O)
|
