buildroot/package/pkg-generic.mk

1134 lines
39 KiB
Makefile
Raw Normal View History

################################################################################
# Generic package infrastructure
#
# This file implements an infrastructure that eases development of
# package .mk files. It should be used for packages that do not rely
# on a well-known build system for which Buildroot has a dedicated
# infrastructure (so far, Buildroot has special support for
# autotools-based and CMake-based packages).
#
# See the Buildroot documentation for details on the usage of this
# infrastructure
#
# In terms of implementation, this generic infrastructure requires the
# .mk file to specify:
#
# 1. Metadata information about the package: name, version,
# download URL, etc.
#
# 2. Description of the commands to be executed to configure, build
# and install the package
################################################################################
################################################################################
# Helper functions to catch start/end of each step
################################################################################
# Those two functions are called by each step below.
# They are responsible for calling all hooks defined in
# $(GLOBAL_INSTRUMENTATION_HOOKS) and pass each of them
# three arguments:
# $1: either 'start' or 'end'
# $2: the name of the step
# $3: the name of the package
# Start step
# $1: step name
define step_start
$(foreach hook,$(GLOBAL_INSTRUMENTATION_HOOKS),$(call $(hook),start,$(1),$($(PKG)_NAME))$(sep))
endef
# End step
# $1: step name
define step_end
$(foreach hook,$(GLOBAL_INSTRUMENTATION_HOOKS),$(call $(hook),end,$(1),$($(PKG)_NAME))$(sep))
endef
#######################################
# Actual steps hooks
# Time steps
define step_time
printf "%s:%-5.5s:%-20.20s: %s\n" \
"$$(date +%s.%N)" "$(1)" "$(2)" "$(3)" \
>>"$(BUILD_DIR)/build-time.log"
endef
GLOBAL_INSTRUMENTATION_HOOKS += step_time
# Hooks to collect statistics about installed files
# The suffix is typically empty for the target variant, for legacy backward
# compatibility.
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
# $(1): package name
# $(2): base directory to search in
# $(3): suffix of file (optional)
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
define step_pkg_size_inner
core/pkg-infra: restore completeness of packages files lists In commit 7fb6e782542f (core/instrumentation: shave minutes off the build time), the built stampfile is used as a reference to detect files installed by a package. However, packages may install files keeping their mtime intact, and we end up not detecting this. For example, the internal skeleton package will install (e.g.) /etc/passwd with an mtime of when the file was created in $(TOP_DIR), which could be the time the git repository was checked out; that mtime is always older than the build stamp file, so files installed by the skeleton package are never accounted for to that package, or to any other package for that matters. We switch to an alternate solution, which consists of storing some extra metadata per file, so that we can more reasily detect modifications to the files. Then we compare the state before the package is installed (by reusing the existing list) and after the package is installed, compare that to list any new file or modified files (in reality, ignoring untouched and removed files). Finally, we store the file->package association in the global list and store the new stat list as the global list. The format used for the .stat file is: mtime:inode:perms:filetype:size,filename Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> [Peter: rename files, reformat, only look for files and symlinks and pass LC_ALL=C to comm as pointed out by Thomas De Schampheleire] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-02-06 07:37:51 -07:00
@touch $(BUILD_DIR)/.files-list$(3).stat
@touch $(BUILD_DIR)/packages-file-list$(3).txt
$(SED) '/^$(1),/d' $(BUILD_DIR)/packages-file-list$(3).txt
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
cd $(2); \
core/pkg-infra: restore completeness of packages files lists In commit 7fb6e782542f (core/instrumentation: shave minutes off the build time), the built stampfile is used as a reference to detect files installed by a package. However, packages may install files keeping their mtime intact, and we end up not detecting this. For example, the internal skeleton package will install (e.g.) /etc/passwd with an mtime of when the file was created in $(TOP_DIR), which could be the time the git repository was checked out; that mtime is always older than the build stamp file, so files installed by the skeleton package are never accounted for to that package, or to any other package for that matters. We switch to an alternate solution, which consists of storing some extra metadata per file, so that we can more reasily detect modifications to the files. Then we compare the state before the package is installed (by reusing the existing list) and after the package is installed, compare that to list any new file or modified files (in reality, ignoring untouched and removed files). Finally, we store the file->package association in the global list and store the new stat list as the global list. The format used for the .stat file is: mtime:inode:perms:filetype:size,filename Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> [Peter: rename files, reformat, only look for files and symlinks and pass LC_ALL=C to comm as pointed out by Thomas De Schampheleire] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-02-06 07:37:51 -07:00
LC_ALL=C find . \( -type f -o -type l \) -printf '%T@:%i:%#m:%y:%s,%p\n' \
| LC_ALL=C sort > $(BUILD_DIR)/.files-list$(3).new
LC_ALL=C comm -13 \
$(BUILD_DIR)/.files-list$(3).stat \
$(BUILD_DIR)/.files-list$(3).new \
> $($(PKG)_BUILDDIR)/.files-list$(3).txt
sed -r -e 's/^[^,]+/$(1)/' \
$($(PKG)_BUILDDIR)/.files-list$(3).txt \
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
>> $(BUILD_DIR)/packages-file-list$(3).txt
core/pkg-infra: restore completeness of packages files lists In commit 7fb6e782542f (core/instrumentation: shave minutes off the build time), the built stampfile is used as a reference to detect files installed by a package. However, packages may install files keeping their mtime intact, and we end up not detecting this. For example, the internal skeleton package will install (e.g.) /etc/passwd with an mtime of when the file was created in $(TOP_DIR), which could be the time the git repository was checked out; that mtime is always older than the build stamp file, so files installed by the skeleton package are never accounted for to that package, or to any other package for that matters. We switch to an alternate solution, which consists of storing some extra metadata per file, so that we can more reasily detect modifications to the files. Then we compare the state before the package is installed (by reusing the existing list) and after the package is installed, compare that to list any new file or modified files (in reality, ignoring untouched and removed files). Finally, we store the file->package association in the global list and store the new stat list as the global list. The format used for the .stat file is: mtime:inode:perms:filetype:size,filename Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> [Peter: rename files, reformat, only look for files and symlinks and pass LC_ALL=C to comm as pointed out by Thomas De Schampheleire] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-02-06 07:37:51 -07:00
mv $(BUILD_DIR)/.files-list$(3).new \
$(BUILD_DIR)/.files-list$(3).stat
endef
define step_pkg_size
$(if $(filter install-target,$(2)),\
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
$(if $(filter end,$(1)),$(call step_pkg_size_inner,$(3),$(TARGET_DIR))))
$(if $(filter install-staging,$(2)),\
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
$(if $(filter end,$(1)),$(call step_pkg_size_inner,$(3),$(STAGING_DIR),-staging)))
$(if $(filter install-host,$(2)),\
core/instrumentation: shave minutes off the build time As part of the build, we run some instrumentation hooks to gather statistics about the usage of the target/, staging/ and host/ directories, so that we can generate reports for the user, that shows: - for each file, what package installed it, - for each package,the size that it installed. In so doing, we run a double md5 pass on all files of the affected directories (before/after installation). These passes were mostly invisible when we were only scanning target/, but has greatly increased in time now that we also scan staging/ and host/ (but only in the corresponding _CMDS, of course). This md5 was mostly aimed at catching packages that would "cheat" with mtime/atime/ctime somehow. They can't really cheat on md5, though [0]. Timings however speak for themselves, with this defconfig (slightly biggish-but-still-manageable build) [1]. host/ 20965 files 1.2GiB staging/ 4715 files 333MiB target/ 1801 files 44MiB All instrumentation steps, using md5: 19min 27s All instrumentation steps, using mtime: 14min 45s No instrumentation step at all: 14min 31s So, using mtime is an almost-5min improvement, i.e. about 25% faster, while removing all instrumentation steps does not gain that much more... So, we switch to using mtime, because in the end that's still good-enough for our use-case: generating some graphs. It is not mission-critical, and if a graph is slightly off, that's not a biggy. It can anyway be attributed to a broken package's buildsystem, which should get fixed. However, we lose the ability to track directories. Non-empty directories can be tracked back by a bit of scripting, but empty directories are simply not caught. If we were to also look for directories using mtime, we would catch parents of installed files: - /foo/bar/ exists - a package installs /foo/bar/buz - mtime of /foo/bar/ is changed to account for the new file in it. So we do not track directories at all, and we lose empty directories. The existing tracking was mostly happenstance, with the original submission and comments not really accounting for a real use-case. Now, we also change the way we handle symlinks. Previously, we would hash the file pointed to by the symlink. Now, we only look at the mtime of the symlink itself, which still detects modifications. Eventually, this also means that we now no longer need to establish a list before the install step; we can now simply run after the install step, finding any files newer than the build stamp. [0] Yeah, md5 is very weak, but we're not guarding against malicious attacks, just about careless modifications. [1] defconfig used for tests: BR2_arm=y BR2_cortex_a7=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VIRGL=y BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y BR2_PACKAGE_MESA3D_OSMESA=y BR2_PACKAGE_MESA3D_OPENGL_ES=y BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY=y BR2_PACKAGE_SYSTEMD_BACKLIGHT=y BR2_PACKAGE_SYSTEMD_BINFMT=y BR2_PACKAGE_SYSTEMD_COREDUMP=y BR2_PACKAGE_SYSTEMD_FIRSTBOOT=y BR2_PACKAGE_SYSTEMD_HIBERNATE=y BR2_PACKAGE_SYSTEMD_IMPORTD=y BR2_PACKAGE_SYSTEMD_LOCALED=y BR2_PACKAGE_SYSTEMD_LOGIND=y BR2_PACKAGE_SYSTEMD_MACHINED=y BR2_PACKAGE_SYSTEMD_POLKIT=y BR2_PACKAGE_SYSTEMD_QUOTACHECK=y BR2_PACKAGE_SYSTEMD_RANDOMSEED=y BR2_PACKAGE_SYSTEMD_RFKILL=y BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT=y BR2_PACKAGE_SYSTEMD_SYSUSERS=y BR2_PACKAGE_SYSTEMD_VCONSOLE=y [Peter: tweak commit message, use find -type l] Reported-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Trent Piepho <tpiepho@impinj.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-15 14:35:08 -06:00
$(if $(filter end,$(1)),$(call step_pkg_size_inner,$(3),$(HOST_DIR),-host)))
endef
GLOBAL_INSTRUMENTATION_HOOKS += step_pkg_size
Makefile: add check of binaries architecture As shown recently by the firejail example, it is easy to miss that a package builds and installs binaries without actually cross-compiling them: they are built for the host architecture instead of the target architecture. This commit adds a small helper script, check-bin-arch, called as a GLOBAL_INSTRUMENTATION_HOOKS at the end of the target installation of each package, to verify that the files installed by this package have been built for the correct architecture. Being called as a GLOBAL_INSTRUMENTATION_HOOKS allows the build to error out right after the installation of the faulty package, and therefore get autobuilder error detection properly assigned to this specific package. Example output with the firejail package enabled, when building for an ARM target: ERROR: architecture for ./usr/lib/firejail/libconnect.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firejail is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/libtrace.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/libtracelog.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/ftee is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/faudit is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firemon is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firecfg is Advanced Micro Devices X86-64, should be ARM Many thanks to Yann E. Morin and Arnout Vandecappelle for their reviews and suggestions. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-19 07:07:52 -06:00
# Relies on step_pkg_size, so must be after
define check_bin_arch
$(if $(filter end-install-target,$(1)-$(2)),\
support/scripts/check-bin-arch -p $(3) \
-l $(BUILD_DIR)/packages-file-list.txt \
$(foreach i,$($(PKG)_BIN_ARCH_EXCLUDE),-i "$(i)") \
Makefile: add check of binaries architecture As shown recently by the firejail example, it is easy to miss that a package builds and installs binaries without actually cross-compiling them: they are built for the host architecture instead of the target architecture. This commit adds a small helper script, check-bin-arch, called as a GLOBAL_INSTRUMENTATION_HOOKS at the end of the target installation of each package, to verify that the files installed by this package have been built for the correct architecture. Being called as a GLOBAL_INSTRUMENTATION_HOOKS allows the build to error out right after the installation of the faulty package, and therefore get autobuilder error detection properly assigned to this specific package. Example output with the firejail package enabled, when building for an ARM target: ERROR: architecture for ./usr/lib/firejail/libconnect.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firejail is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/libtrace.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/libtracelog.so is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/ftee is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/lib/firejail/faudit is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firemon is Advanced Micro Devices X86-64, should be ARM ERROR: architecture for ./usr/bin/firecfg is Advanced Micro Devices X86-64, should be ARM Many thanks to Yann E. Morin and Arnout Vandecappelle for their reviews and suggestions. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-19 07:07:52 -06:00
-r $(TARGET_READELF) \
-a $(BR2_READELF_ARCH_NAME))
endef
GLOBAL_INSTRUMENTATION_HOOKS += check_bin_arch
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 14:48:51 -07:00
# This hook checks that host packages that need libraries that we build
# have a proper DT_RPATH or DT_RUNPATH tag
define check_host_rpath
$(if $(filter install-host,$(2)),\
$(if $(filter end,$(1)),support/scripts/check-host-rpath $(3) $(HOST_DIR)))
endef
GLOBAL_INSTRUMENTATION_HOOKS += check_host_rpath
define step_check_build_dir_one
if [ -d $(2) ]; then \
printf "%s: installs files in %s\n" $(1) $(2) >&2; \
exit 1; \
fi
endef
define step_check_build_dir
$(if $(filter install-staging,$(2)),\
$(if $(filter end,$(1)),$(call step_check_build_dir_one,$(3),$(STAGING_DIR)/$(O))))
$(if $(filter install-target,$(2)),\
$(if $(filter end,$(1)),$(call step_check_build_dir_one,$(3),$(TARGET_DIR)/$(O))))
endef
GLOBAL_INSTRUMENTATION_HOOKS += step_check_build_dir
# User-supplied script
ifneq ($(BR2_INSTRUMENTATION_SCRIPTS),)
define step_user
@$(foreach user_hook, $(BR2_INSTRUMENTATION_SCRIPTS), \
$(EXTRA_ENV) $(user_hook) "$(1)" "$(2)" "$(3)"$(sep))
endef
GLOBAL_INSTRUMENTATION_HOOKS += step_user
endif
################################################################################
# Implicit targets -- produce a stamp file for each step of a package build
################################################################################
# Retrieve the archive
$(BUILD_DIR)/%/.stamp_downloaded:
@$(call step_start,download)
$(foreach hook,$($(PKG)_PRE_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
# Only show the download message if it isn't already downloaded
$(Q)for p in $($(PKG)_ALL_DOWNLOADS); do \
if test ! -e $($(PKG)_DL_DIR)/`basename $$p` ; then \
$(call MESSAGE,"Downloading") ; \
break ; \
fi ; \
done
$(foreach p,$($(PKG)_ALL_DOWNLOADS),$(call DOWNLOAD,$(p),$(PKG))$(sep))
$(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
$(Q)mkdir -p $(@D)
@$(call step_end,download)
$(Q)touch $@
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
# Retrieve actual source archive, e.g. for prebuilt external toolchains
$(BUILD_DIR)/%/.stamp_actual_downloaded:
@$(call step_start,actual-download)
$(call DOWNLOAD,$($(PKG)_ACTUAL_SOURCE_SITE)/$($(PKG)_ACTUAL_SOURCE_TARBALL),$(PKG))
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(Q)mkdir -p $(@D)
@$(call step_end,actual-download)
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(Q)touch $@
# Unpack the archive
$(BUILD_DIR)/%/.stamp_extracted:
@$(call step_start,extract)
@$(call MESSAGE,"Extracting")
$(foreach hook,$($(PKG)_PRE_EXTRACT_HOOKS),$(call $(hook))$(sep))
$(Q)mkdir -p $(@D)
$($(PKG)_EXTRACT_CMDS)
# some packages have messed up permissions inside
$(Q)chmod -R +rw $(@D)
$(foreach hook,$($(PKG)_POST_EXTRACT_HOOKS),$(call $(hook))$(sep))
@$(call step_end,extract)
$(Q)touch $@
# Rsync the source directory if the <pkg>_OVERRIDE_SRCDIR feature is
# used.
$(BUILD_DIR)/%/.stamp_rsynced:
@$(call step_start,rsync)
@$(call MESSAGE,"Syncing from source dir $(SRCDIR)")
@mkdir -p $(@D)
$(foreach hook,$($(PKG)_PRE_RSYNC_HOOKS),$(call $(hook))$(sep))
@test -d $(SRCDIR) || (echo "ERROR: $(SRCDIR) does not exist" ; exit 1)
rsync -au --chmod=u=rwX,go=rX $($(PKG)_OVERRIDE_SRCDIR_RSYNC_EXCLUSIONS) $(RSYNC_VCS_EXCLUSIONS) $(call qstrip,$(SRCDIR))/ $(@D)
$(foreach hook,$($(PKG)_POST_RSYNC_HOOKS),$(call $(hook))$(sep))
@$(call step_end,rsync)
$(Q)touch $@
# Patch
#
# The RAWNAME variable is the lowercased package name, which allows to
# find the package directory (typically package/<pkgname>) and the
# prefix of the patches
#
# For BR2_GLOBAL_PATCH_DIR, only generate if it is defined
$(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS = $(PKGDIR)
$(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS += $(addsuffix /$(RAWNAME),$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))
$(BUILD_DIR)/%/.stamp_patched:
@$(call step_start,patch)
@$(call MESSAGE,"Patching")
$(foreach hook,$($(PKG)_PRE_PATCH_HOOKS),$(call $(hook))$(sep))
$(foreach p,$($(PKG)_PATCH),$(APPLY_PATCHES) $(@D) $($(PKG)_DL_DIR) $(notdir $(p))$(sep))
$(Q)( \
for D in $(PATCH_BASE_DIRS); do \
if test -d $${D}; then \
if test -d $${D}/$($(PKG)_VERSION); then \
$(APPLY_PATCHES) $(@D) $${D}/$($(PKG)_VERSION) \*.patch \*.patch.$(ARCH) || exit 1; \
else \
$(APPLY_PATCHES) $(@D) $${D} \*.patch \*.patch.$(ARCH) || exit 1; \
fi; \
fi; \
done; \
)
$(foreach hook,$($(PKG)_POST_PATCH_HOOKS),$(call $(hook))$(sep))
@$(call step_end,patch)
$(Q)touch $@
# Check that all directories specified in BR2_GLOBAL_PATCH_DIR exist.
$(foreach dir,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)),\
$(if $(wildcard $(dir)),,\
$(error BR2_GLOBAL_PATCH_DIR contains nonexistent directory $(dir))))
# Configure
$(BUILD_DIR)/%/.stamp_configured:
@$(call step_start,configure)
@$(call MESSAGE,"Configuring")
$(foreach hook,$($(PKG)_PRE_CONFIGURE_HOOKS),$(call $(hook))$(sep))
$($(PKG)_CONFIGURE_CMDS)
$(foreach hook,$($(PKG)_POST_CONFIGURE_HOOKS),$(call $(hook))$(sep))
@$(call step_end,configure)
$(Q)touch $@
# Build
$(BUILD_DIR)/%/.stamp_built::
@$(call step_start,build)
@$(call MESSAGE,"Building")
$(foreach hook,$($(PKG)_PRE_BUILD_HOOKS),$(call $(hook))$(sep))
+$($(PKG)_BUILD_CMDS)
$(foreach hook,$($(PKG)_POST_BUILD_HOOKS),$(call $(hook))$(sep))
@$(call step_end,build)
$(Q)touch $@
# Install to host dir
$(BUILD_DIR)/%/.stamp_host_installed:
@$(call step_start,install-host)
@$(call MESSAGE,"Installing to host directory")
@mkdir -p $(HOST_DIR)
$(foreach hook,$($(PKG)_PRE_INSTALL_HOOKS),$(call $(hook))$(sep))
+$($(PKG)_INSTALL_CMDS)
$(foreach hook,$($(PKG)_POST_INSTALL_HOOKS),$(call $(hook))$(sep))
@$(call step_end,install-host)
$(Q)touch $@
# Install to staging dir
#
# Some packages install libtool .la files alongside any installed
# libraries. These .la files sometimes refer to paths relative to the
# sysroot, which libtool will interpret as absolute paths to host
# libraries instead of the target libraries. Since this is not what we
# want, these paths are fixed by prefixing them with $(STAGING_DIR).
# As we configure with --prefix=/usr, this fix needs to be applied to
# any path that starts with /usr.
#
# To protect against the case that the output or staging directories or
# the pre-installed external toolchain themselves are under /usr, we first
# substitute away any occurrences of these directories with @BASE_DIR@,
# @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@ respectively.
#
# Note that STAGING_DIR can be outside BASE_DIR when the user sets
# BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
# can be under @BASE_DIR@ when it's a downloaded toolchain, and can be
# empty when we use an internal toolchain.
#
$(BUILD_DIR)/%/.stamp_staging_installed:
@$(call step_start,install-staging)
@$(call MESSAGE,"Installing to staging directory")
@mkdir -p $(STAGING_DIR)
$(foreach hook,$($(PKG)_PRE_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
+$($(PKG)_INSTALL_STAGING_CMDS)
$(foreach hook,$($(PKG)_POST_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
$(Q)if test -n "$($(PKG)_CONFIG_SCRIPTS)" ; then \
$(call MESSAGE,"Fixing package configuration files") ;\
package/pkg-generic: adjust config scripts tweaks for per-package directories This commit adjusts the logic in pkg-generic.mk that tweaks the *-config shell scripts installed by various libraries to make it compatible with per-package directories. This requires two fixes: - replacing $(STAGING_DIR) with a relative path from the config script to the staging directory, rather than using an absolute path of the staging directory. Without this, a *-config script provided by package A, but called from package B per-package directory will return paths from package A per-package directory: $ ./output/per-package/mcrypt/host/usr/<tuple>/sysroot/usr/bin/libmcrypt-config --libs -L..../output/per-package/libmcrypt/host/usr/<tuple>/sysroot/usr/lib/ The libmcrypt-config script is installed by the libmcrypt package, and mcrypt is a package that depends on libmcrypt. When we call the libmcrypt-config script from the mcrypt per-package directory, it returns a -L flag that points to the libmcrypt per-package directory. One might say: but this is OK, since the sysroot of the libmcrypt per-package directory also contains the libmcrypt library. This is true, but we encounter a more subtle issue: because -L paths are considered before standard paths, ld ends up finding libc.so in the libmcrypt per-package directory. This libc.so file is a linker script that looks like this: GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.3 ) ) Normally, thanks to ld sysroot awareness, /lib/libc.so.6 in this script is re-interpreted according to the sysroot. But in this case, the library is *outside* the compiler sysroot. Remember: we are using the compiler/linker from the "mcrypt" per-package directory, but we found "libc.so.6" in the "libmcrypt" per-package directory. This causes the linker to really use the /lib/libc.so.6 from the host machine, obvisouly leading to a build failure such as: output/per-package/libgcrypt/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/7.3.1/../../../../nios2-linux-gnu/bin/ld: cannot find /lib/libc.so.6 output/per-package/libgcrypt/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/7.3.1/../../../../nios2-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a output/per-package/libgcrypt/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/7.3.1/../../../../nios2-linux-gnu/bin/ld: cannot find /lib/ld-linux-nios2.so.1 - Some *-config scripts, such as the apr-1-config script, contain references to host tools: CC=".../output/per-package/apr/hosr/bin/arm-linux-gcc" CCP=".../output/per-package/apr/hosr/bin/arm-linux-cpp" We also want to replace those with proper relative paths. To achieve this, we need to also replace $(HOST_DIR) with a relative path. Since $(STAGING_DIR) is inside $(HOST_DIR), the first replacement of $(STAGING_DIR) by @STAGING_DIR@ is no longer needed: replacing $(HOST_DIR) by @HOST_DIR@ is sufficient. We still need to replace @STAGING_DIR@ by the proper path though, as we introduce @STAGING_DIR@ references in exec_prefix and prefix variables, as well as -I and -L flags. 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 07:58:11 -07:00
$(SED) "s,$(HOST_DIR),@HOST_DIR@,g" \
-e "s,$(BASE_DIR),@BASE_DIR@,g" \
-e "s,^\(exec_\)\?prefix=.*,\1prefix=@STAGING_DIR@/usr,g" \
-e "s,-I/usr/,-I@STAGING_DIR@/usr/,g" \
-e "s,-L/usr/,-L@STAGING_DIR@/usr/,g" \
-e 's,@STAGING_DIR@,$$(dirname $$(readlink -e $$0))/../..,g' \
-e 's,@HOST_DIR@,$$(dirname $$(readlink -e $$0))/../../../..,g' \
-e "s,@BASE_DIR@,$(BASE_DIR),g" \
$(addprefix $(STAGING_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ;\
fi
@$(call MESSAGE,"Fixing libtool files")
for la in $$(find $(STAGING_DIR)/usr/lib* -name "*.la"); do \
cp -a "$${la}" "$${la}.fixed" && \
$(SED) "s:$(BASE_DIR):@BASE_DIR@:g" \
-e "s:$(STAGING_DIR):@STAGING_DIR@:g" \
$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
-e "s:\(['= ]\)/usr:\\1@STAGING_DIR@/usr:g" \
$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
-e "s:@BASE_DIR@:$(BASE_DIR):g" \
"$${la}.fixed" && \
if cmp -s "$${la}" "$${la}.fixed"; then \
rm -f "$${la}.fixed"; \
else \
mv "$${la}.fixed" "$${la}"; \
fi || exit 1; \
done
@$(call step_end,install-staging)
$(Q)touch $@
# Install to images dir
$(BUILD_DIR)/%/.stamp_images_installed:
@$(call step_start,install-image)
@mkdir -p $(BINARIES_DIR)
$(foreach hook,$($(PKG)_PRE_INSTALL_IMAGES_HOOKS),$(call $(hook))$(sep))
@$(call MESSAGE,"Installing to images directory")
+$($(PKG)_INSTALL_IMAGES_CMDS)
$(foreach hook,$($(PKG)_POST_INSTALL_IMAGES_HOOKS),$(call $(hook))$(sep))
@$(call step_end,install-image)
$(Q)touch $@
# Install to target dir
$(BUILD_DIR)/%/.stamp_target_installed:
@$(call step_start,install-target)
@$(call MESSAGE,"Installing to target")
@mkdir -p $(TARGET_DIR)
$(foreach hook,$($(PKG)_PRE_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep))
+$($(PKG)_INSTALL_TARGET_CMDS)
$(if $(BR2_INIT_SYSTEMD),\
$($(PKG)_INSTALL_INIT_SYSTEMD))
$(if $(BR2_INIT_SYSV)$(BR2_INIT_BUSYBOX),\
$($(PKG)_INSTALL_INIT_SYSV))
$(if $(BR2_INIT_OPENRC), \
$(or $($(PKG)_INSTALL_INIT_OPENRC), \
$($(PKG)_INSTALL_INIT_SYSV)))
$(foreach hook,$($(PKG)_POST_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep))
$(Q)if test -n "$($(PKG)_CONFIG_SCRIPTS)" ; then \
$(RM) -f $(addprefix $(TARGET_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ; \
fi
@$(call step_end,install-target)
$(Q)touch $@
# Remove package sources
$(BUILD_DIR)/%/.stamp_dircleaned:
rm -Rf $(@D)
infra/pkg-virtual: validate only one provider provides an implementation Currently, it is possible that more than one provider of a virtual package is selected in the menuconfig. This leads to autobuild failures, and we do not protect the user from making a mistake in the configuration. The failure is then hard to troubleshoot in any case. We can't use kconfig constructs to prevent this, since kconfig does not tell how many options did a select on another option. This change introduces a new variable a provider *must* define to include all the virtual packages it is an implementation of. Then, when evaluating the package's rules, we check that the provider is indeed the declared one for each virtual package it claims to be an implementation of. This works by taking advantage that when more than one provider is selected, only one of them will 'win' in setting the _PROVIDES_FOO option. Thus any provider just has to check it is indeed the declared provider. If not, it means that one or more other provider is selected. This gives the opportunity to the user to change its configuration, and we can match the error message in the autobuilders to skip those failures (we can skip them instead of reporting them, since they are obviously configuration errors that should not happen in the first place.) [Note: kudos to Arnout for suggesting this actual implementation. :-)] Fixes: http://autobuild.buildroot.org/results/285/2851069d6964aa46d26b4aabe7d84e8c0c6c72ce http://autobuild.buildroot.net/results/9b7/9b7870354d70e27e42d3d9c1f131ab54706bf20e [...] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-15 11:37:03 -06:00
################################################################################
# virt-provides-single -- check that provider-pkg is the declared provider for
# the virtual package virt-pkg
#
# argument 1 is the lower-case name of the virtual package
# argument 2 is the upper-case name of the virtual package
# argument 3 is the lower-case name of the provider
#
# example:
# $(call virt-provides-single,libegl,LIBEGL,rpi-userland)
################################################################################
define virt-provides-single
ifneq ($$(call qstrip,$$(BR2_PACKAGE_PROVIDES_$(2))),$(3))
$$(error Configuration error: both "$(3)" and $$(BR2_PACKAGE_PROVIDES_$(2))\
are selected as providers for virtual package "$(1)". Only one provider can\
be selected at a time. Please fix your configuration)
endif
endef
define pkg-graph-depends
@$$(INSTALL) -d $$(GRAPHS_DIR)
@cd "$$(CONFIG_DIR)"; \
$$(TOPDIR)/support/scripts/graph-depends $$(BR2_GRAPH_DEPS_OPTS) \
-p $(1) $(2) -o $$(GRAPHS_DIR)/$$(@).dot
dot $$(BR2_GRAPH_DOT_OPTS) -T$$(BR_GRAPH_OUT) \
-o $$(GRAPHS_DIR)/$$(@).$$(BR_GRAPH_OUT) \
$$(GRAPHS_DIR)/$$(@).dot
endef
################################################################################
# inner-generic-package -- generates the make targets needed to build a
# generic package
#
# argument 1 is the lowercase package name
# argument 2 is the uppercase package name, including a HOST_ prefix
# for host packages
# argument 3 is the uppercase package name, without the HOST_ prefix
# for host packages
# argument 4 is the type (target or host)
#
# Note about variable and function references: inside all blocks that are
# evaluated with $(eval), which includes all 'inner-xxx-package' blocks,
# specific rules apply with respect to variable and function references.
# - Numbered variables (parameters to the block) can be referenced with a single
# dollar sign: $(1), $(2), $(3), etc.
# - pkgdir and pkgname should be referenced with a single dollar sign too. These
# functions rely on 'the most recently parsed makefile' which is supposed to
# be the package .mk file. If we defer the evaluation of these functions using
# double dollar signs, then they may be evaluated too late, when other
# makefiles have already been parsed. One specific case is when $$(pkgdir) is
# assigned to a variable using deferred evaluation with '=' and this variable
# is used in a target rule outside the eval'ed inner block. In this case, the
# pkgdir will be that of the last makefile parsed by buildroot, which is not
# the expected value. This mechanism is for example used for the TARGET_PATCH
# rule.
# - All other variables should be referenced with a double dollar sign:
# $$(TARGET_DIR), $$($(2)_VERSION), etc. Also all make functions should be
# referenced with a double dollar sign: $$(subst), $$(call), $$(filter-out),
# etc. This rule ensures that these variables and functions are only expanded
# during the $(eval) step, and not earlier. Otherwise, unintuitive and
# undesired behavior occurs with respect to these variables and functions.
#
################################################################################
define inner-generic-package
# When doing a package, we're definitely not doing a rootfs, but we
# may inherit it via the dependency chain, so we reset it.
$(1): ROOTFS=
# Ensure the package is only declared once, i.e. do not accept that a
# package be re-defined by a br2-external tree
ifneq ($(call strip,$(filter $(1),$(PACKAGES_ALL))),)
$$(error Package '$(1)' defined a second time in '$(pkgdir)'; \
previous definition was in '$$($(2)_PKGDIR)')
endif
PACKAGES_ALL += $(1)
# Define default values for various package-related variables, if not
# already defined. For some variables (version, source, site and
# subdir), if they are undefined, we try to see if a variable without
# the HOST_ prefix is defined. If so, we use such a variable, so that
# this information has only to be specified once, for both the
# target and host packages of a given .mk file.
$(2)_TYPE = $(4)
$(2)_NAME = $(1)
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_RAWNAME = $$(patsubst host-%,%,$(1))
$(2)_PKGDIR = $(pkgdir)
# Keep the package version that may contain forward slashes in the _DL_VERSION
# variable, then replace all forward slashes ('/') by underscores ('_') to
# sanitize the package version that is used in paths, directory and file names.
# Forward slashes may appear in the package's version when pointing to a
# version control system branch or tag, for example remotes/origin/1_10_stable.
# Similar for spaces and colons (:) that may appear in date-based revisions for
# CVS.
ifndef $(2)_VERSION
ifdef $(3)_DL_VERSION
$(2)_DL_VERSION := $$($(3)_DL_VERSION)
else ifdef $(3)_VERSION
$(2)_DL_VERSION := $$($(3)_VERSION)
endif
else
$(2)_DL_VERSION := $$(strip $$($(2)_VERSION))
endif
$(2)_VERSION := $$(call sanitize,$$($(2)_DL_VERSION))
$(2)_HASH_FILE = \
$$(strip \
$$(if $$(wildcard $$($(2)_PKGDIR)/$$($(2)_VERSION)/$$($(2)_RAWNAME).hash),\
$$($(2)_PKGDIR)/$$($(2)_VERSION)/$$($(2)_RAWNAME).hash,\
$$($(2)_PKGDIR)/$$($(2)_RAWNAME).hash))
ifdef $(3)_OVERRIDE_SRCDIR
$(2)_OVERRIDE_SRCDIR ?= $$($(3)_OVERRIDE_SRCDIR)
endif
core: rename FOO_BASE_NAME to FOO_BASENAME to avoid clashes In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-06 05:59:23 -07:00
$(2)_BASENAME = $$(if $$($(2)_VERSION),$(1)-$$($(2)_VERSION),$(1))
$(2)_BASENAME_RAW = $$(if $$($(2)_VERSION),$$($(2)_RAWNAME)-$$($(2)_VERSION),$$($(2)_RAWNAME))
$(2)_DL_SUBDIR ?= $$($(2)_RAWNAME)
$(2)_DL_DIR = $$(DL_DIR)/$$($(2)_DL_SUBDIR)
core: rename FOO_BASE_NAME to FOO_BASENAME to avoid clashes In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-06 05:59:23 -07:00
$(2)_DIR = $$(BUILD_DIR)/$$($(2)_BASENAME)
ifndef $(2)_SUBDIR
ifdef $(3)_SUBDIR
$(2)_SUBDIR = $$($(3)_SUBDIR)
else
$(2)_SUBDIR ?=
endif
endif
ifndef $(2)_STRIP_COMPONENTS
ifdef $(3)_STRIP_COMPONENTS
$(2)_STRIP_COMPONENTS = $$($(3)_STRIP_COMPONENTS)
else
$(2)_STRIP_COMPONENTS ?= 1
endif
endif
$(2)_SRCDIR = $$($(2)_DIR)/$$($(2)_SUBDIR)
$(2)_BUILDDIR ?= $$($(2)_SRCDIR)
ifneq ($$($(2)_OVERRIDE_SRCDIR),)
$(2)_VERSION = custom
endif
ifndef $(2)_SOURCE
ifdef $(3)_SOURCE
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_SOURCE = $$($(3)_SOURCE)
else ifdef $(2)_VERSION
core: rename FOO_BASE_NAME to FOO_BASENAME to avoid clashes In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-06 05:59:23 -07:00
$(2)_SOURCE ?= $$($(2)_BASENAME_RAW).tar.gz
endif
endif
# If FOO_ACTUAL_SOURCE_TARBALL is explicitly defined, it means FOO_SOURCE is
# indeed a binary (e.g. external toolchain) and FOO_ACTUAL_SOURCE_TARBALL/_SITE
# point to the actual sources tarball. Use the actual sources for legal-info.
# For most packages the FOO_SITE/FOO_SOURCE pair points to real source code,
# so these are the defaults for FOO_ACTUAL_*.
$(2)_ACTUAL_SOURCE_TARBALL ?= $$($(2)_SOURCE)
$(2)_ACTUAL_SOURCE_SITE ?= $$(call qstrip,$$($(2)_SITE))
ifndef $(2)_PATCH
ifdef $(3)_PATCH
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_PATCH = $$($(3)_PATCH)
endif
endif
$(2)_ALL_DOWNLOADS = \
$$(if $$($(2)_SOURCE),$$($(2)_SITE_METHOD)+$$($(2)_SITE)/$$($(2)_SOURCE)) \
$$(foreach p,$$($(2)_PATCH) $$($(2)_EXTRA_DOWNLOADS),\
$$(if $$(findstring ://,$$(p)),$$(p),\
$$($(2)_SITE)/$$(p)))
ifndef $(2)_SITE
ifdef $(3)_SITE
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_SITE = $$($(3)_SITE)
endif
endif
ifndef $(2)_SITE_METHOD
ifdef $(3)_SITE_METHOD
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_SITE_METHOD = $$($(3)_SITE_METHOD)
else
# Try automatic detection using the scheme part of the URI
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_SITE_METHOD = $$(call geturischeme,$$($(2)_SITE))
endif
endif
ifneq ($$(filter bzr cvs hg svn,$$($(2)_SITE_METHOD)),)
BR_NO_CHECK_HASH_FOR += $$($(2)_SOURCE)
endif
# Do not accept to download git submodule if not using the git method
ifneq ($$($(2)_GIT_SUBMODULES),)
ifneq ($$($(2)_SITE_METHOD),git)
$$(error $(2) declares having git sub-modules, but does not use the \
'git' method (uses '$$($(2)_SITE_METHOD)' instead))
endif
endif
ifeq ($$($(2)_SITE_METHOD),local)
ifeq ($$($(2)_OVERRIDE_SRCDIR),)
$(2)_OVERRIDE_SRCDIR = $$($(2)_SITE)
endif
ifeq ($$($(2)_OVERRIDE_SRCDIR),)
$$(error $(1) has local site method, but `$(2)_SITE` is not defined)
endif
endif
ifndef $(2)_LICENSE
ifdef $(3)_LICENSE
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_LICENSE = $$($(3)_LICENSE)
endif
endif
$(2)_LICENSE ?= unknown
ifndef $(2)_LICENSE_FILES
ifdef $(3)_LICENSE_FILES
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_LICENSE_FILES = $$($(3)_LICENSE_FILES)
endif
endif
ifndef $(2)_REDISTRIBUTE
ifdef $(3)_REDISTRIBUTE
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$(2)_REDISTRIBUTE = $$($(3)_REDISTRIBUTE)
endif
endif
$(2)_REDISTRIBUTE ?= YES
core: rename FOO_BASE_NAME to FOO_BASENAME to avoid clashes In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-06 05:59:23 -07:00
$(2)_REDIST_SOURCES_DIR = $$(REDIST_SOURCES_DIR_$$(call UPPERCASE,$(4)))/$$($(2)_BASENAME_RAW)
# When a target package is a toolchain dependency set this variable to
# 'NO' so the 'toolchain' dependency is not added to prevent a circular
# dependency.
# Similarly for the skeleton.
$(2)_ADD_TOOLCHAIN_DEPENDENCY ?= YES
$(2)_ADD_SKELETON_DEPENDENCY ?= YES
ifeq ($(4),target)
ifeq ($$($(2)_ADD_SKELETON_DEPENDENCY),YES)
$(2)_DEPENDENCIES += skeleton
endif
ifeq ($$($(2)_ADD_TOOLCHAIN_DEPENDENCY),YES)
$(2)_DEPENDENCIES += toolchain
endif
endif
ifneq ($(1),host-skeleton)
$(2)_DEPENDENCIES += host-skeleton
endif
ifneq ($$(filter cvs git svn,$$($(2)_SITE_METHOD)),)
$(2)_DOWNLOAD_DEPENDENCIES += \
$(BR2_GZIP_HOST_DEPENDENCY) \
$(BR2_TAR_HOST_DEPENDENCY)
endif
ifeq ($$(filter host-tar host-skeleton host-fakedate,$(1)),)
$(2)_EXTRACT_DEPENDENCIES += $$(BR2_TAR_HOST_DEPENDENCY)
endif
ifeq ($$(filter host-tar host-skeleton host-xz host-lzip host-fakedate,$(1)),)
ifneq ($$(filter .xz .lzma,$$(suffix $$($(2)_SOURCE))),)
$(2)_EXTRACT_DEPENDENCIES += $$(BR2_XZCAT_HOST_DEPENDENCY)
endif
endif
ifeq ($$(filter host-tar host-skeleton host-xz host-lzip host-fakedate,$(1)),)
ifneq ($$(filter .lz,$$(suffix $$($(2)_SOURCE))),)
$(2)_EXTRACT_DEPENDENCIES += $$(BR2_LZIP_HOST_DEPENDENCY)
endif
endif
ifeq ($$(BR2_CCACHE),y)
ifeq ($$(filter host-tar host-skeleton host-xz host-lzip host-fakedate host-ccache,$(1)),)
$(2)_DEPENDENCIES += host-ccache
endif
endif
ifeq ($$(BR2_REPRODUCIBLE),y)
ifeq ($$(filter host-skeleton host-fakedate,$(1)),)
$(2)_DEPENDENCIES += host-fakedate
endif
endif
# Eliminate duplicates in dependencies
$(2)_FINAL_DEPENDENCIES = $$(sort $$($(2)_DEPENDENCIES))
$(2)_FINAL_DOWNLOAD_DEPENDENCIES = $$(sort $$($(2)_DOWNLOAD_DEPENDENCIES))
$(2)_FINAL_EXTRACT_DEPENDENCIES = $$(sort $$($(2)_EXTRACT_DEPENDENCIES))
$(2)_FINAL_PATCH_DEPENDENCIES = $$(sort $$($(2)_PATCH_DEPENDENCIES))
$(2)_FINAL_ALL_DEPENDENCIES = \
$$(sort \
$$($(2)_FINAL_DEPENDENCIES) \
$$($(2)_FINAL_DOWNLOAD_DEPENDENCIES) \
$$($(2)_FINAL_EXTRACT_DEPENDENCIES) \
$$($(2)_FINAL_PATCH_DEPENDENCIES))
package/pkg-generic: speed up RECURSIVE_FINAL_DEPENDENCIES Evaluating all the <PKG>_RECURSIVE_FINAL_DEPENDENCIES variables (abbreviated RFD hereafter) ends up being quite slow. Enough, on a reasonable modern workstation, to increase the time it takes to run "make printvars" from 13 seconds in 2018.02 to 371 seconds in 2019.02. This patch improves this by using dynamic programming to speed the evaluation of RFD, reducing the before mentioned printvars time to about 14.6 seconds. The evaluation of PKG1_RFD requires recursively evaluating each of PKG1's dependencies' RFDs, then their dependencies' RFDs, and so on. The same is done for PKG2_RFD. But it's likely that many of the dependencies of PKG2 are the same as PKG1. And when we consider all packages, the dependencies are re-computed many thousands of times. To avoid this re-computation we memoize, or save, the computed value of each RFD variable when it found the first time. Subsequent evaluations re-use the memoized value. Surprisingly, this ends up being not all the hard to implement in make. The basic construct is this: VAR = $(if !defined(VAR__X),$(eval VAR__X := value))$(VAR__X) The first time VAR is evaluated VAR__X will not be defined, and code to set VAR__X to the computed value is eval'd. Then the now defined value of VAR__X is returned. Subsequent evaluations can just return VAR__X. It is important to note that VAR is defined with '=', as not enough information (namely, all packages' dependencies) is know when it is parsed to find the correct value. VAR will be evaluated each time it is used. But VAR__X is defined with ":=", so that it is evaluated once when defined, and not each time it is used. 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: Peter Korsgaard <peter@korsgaard.com>
2019-02-25 16:55:14 -07:00
$(2)_FINAL_RECURSIVE_DEPENDENCIES = $$(sort \
$$(if $$(filter undefined,$$(origin $(2)_FINAL_RECURSIVE_DEPENDENCIES__X)), \
$$(eval $(2)_FINAL_RECURSIVE_DEPENDENCIES__X := \
$$(foreach p, \
$$($(2)_FINAL_ALL_DEPENDENCIES), \
$$(p) \
$$($$(call UPPERCASE,$$(p))_FINAL_RECURSIVE_DEPENDENCIES) \
) \
) \
) \
$$($(2)_FINAL_RECURSIVE_DEPENDENCIES__X))
infra/pkg-generic: use pure Makefile-based recursive dependencies Calling to the graph-depends script is very costly, as it calls back to 'make' a lot of time. It turns out that we already have the list of recursive dependencies, so we can just print that. As for the recursive reverse dependencies, we use the same memoisation technique to cut-down on the expansion cost, which would otherwise be on the order of 𝑶(𝑛²) (with 𝑛 enabled packages). >From a defconfig, modified to use glibc, C++, wchar, locales, ssp, and allyespackageconfig (tweaked to avoid multi providers, etc...), the timings for X-show-recursive-rdepends are: before after speedup #rdeps libnss 0m22.932s 0m5.775s 3.97x 3 qt5base 0m41.176s 0m5.781s 7.12x 67 libjpeg 0m56.185s 0m5.749s 9.71x 228 libxml2 0m54.964s 0m5.795s 9.48x 271 freetype 0m46.754s 0m5.819s 8.07x 287 libpng 0m53.577s 0m5.760s 9.30x 303 sqlite 1m15.222s 0m5.807s 12.95x 801 libopenssl 1m25.471s 0m5.844s 14.63x 931 readline 1m13.805s 0m5.775s 12.78x 958 libzlib 1m11.807s 0m5.820s 12.34x 1039 toolchain 1m23.712s 0m6.080s 13.77x 2107 skeleton 1m27.839s 0m6.293s 13.96x 2111 (+1) host-skeleton 1m27.405s 0m6.350s 13.76x 2172 (+2) - speedup: ratio before/after - #rdeps: number of recursive reverse dependencies, with the extra dependencies returned with this patch, see below for the reason. So, for a low-level package with a lot of reverse dependencies, like libzlibz, libopenssl or readline are, the timings are already very much in favour of the change. This is less impressive with packages that have few dependencies (libnss), but still much faster. Also, remember that the config tested has as much packages enabled as possible, so is in itself a degenerate case. With simpler and more realistic configurations, the gains would probably be a bit lower than reported above, but various tests still report good improvements overall (note: coming up with a 'realistic' configuration is pretty hard, as everyone and their dog have their notion of what is realistic in their context, so nothing displayed here; timings are left as an exercise for the interested parties to report aggravation in their cases should they notice some regression). Note that, more recursive reverse dependencies may be displayed now, since we do not apply the exceptions applied in graph-depends. For example, host-skeleton gains two new recursive reverse dependencies: skeleton and toolchain, which are both exceptions in graph-depends. As for direct (not reverse) dependencies: the gain is not as fantastic as for reverse ones, but it is still noticeable, especially thanks to a21212fb7cf (package/pkg-generic: speed up RECURSIVE_FINAL_DEPENDENCIES); just a few examples for %-show-recursive-depends: before after speedup #deps libzlib 0m46.864s 0m5.902s 7.94x 17 qt5base 0m57.590s 0m5.848s 9.85x 190 sqlite 0m46.601s 0m5.816s 8.01x 24 Basically, displaying recursive dependencies, direct or reverse, is almost a constant now: it only slightly varies by about 10% depending on the complexity of the dependency chain, with the parsing of the Makefiles still accounting for the large majority of the time. (PS. Thanks to Joseph for suggesting a list of interesting packages to test, and thanks to Trent for his example of memoisation!) 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: Joseph Kogut <joseph.kogut@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-03 03:16:34 -07:00
$(2)_FINAL_RECURSIVE_RDEPENDENCIES = $$(sort \
$$(if $$(filter undefined,$$(origin $(2)_FINAL_RECURSIVE_RDEPENDENCIES__X)), \
$$(eval $(2)_FINAL_RECURSIVE_RDEPENDENCIES__X := \
$$(foreach p, \
$$($(2)_RDEPENDENCIES), \
$$(p) \
$$($$(call UPPERCASE,$$(p))_FINAL_RECURSIVE_RDEPENDENCIES) \
) \
) \
) \
$$($(2)_FINAL_RECURSIVE_RDEPENDENCIES__X))
$(2)_INSTALL_STAGING ?= NO
$(2)_INSTALL_IMAGES ?= NO
$(2)_INSTALL_TARGET ?= YES
# define sub-target stamps
$(2)_TARGET_INSTALL_TARGET = $$($(2)_DIR)/.stamp_target_installed
$(2)_TARGET_INSTALL_STAGING = $$($(2)_DIR)/.stamp_staging_installed
$(2)_TARGET_INSTALL_IMAGES = $$($(2)_DIR)/.stamp_images_installed
$(2)_TARGET_INSTALL_HOST = $$($(2)_DIR)/.stamp_host_installed
$(2)_TARGET_BUILD = $$($(2)_DIR)/.stamp_built
$(2)_TARGET_CONFIGURE = $$($(2)_DIR)/.stamp_configured
$(2)_TARGET_RSYNC = $$($(2)_DIR)/.stamp_rsynced
$(2)_TARGET_PATCH = $$($(2)_DIR)/.stamp_patched
$(2)_TARGET_EXTRACT = $$($(2)_DIR)/.stamp_extracted
$(2)_TARGET_SOURCE = $$($(2)_DIR)/.stamp_downloaded
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(2)_TARGET_ACTUAL_SOURCE = $$($(2)_DIR)/.stamp_actual_downloaded
$(2)_TARGET_DIRCLEAN = $$($(2)_DIR)/.stamp_dircleaned
# default extract command
$(2)_EXTRACT_CMDS ?= \
$$(if $$($(2)_SOURCE),$$(INFLATE$$(suffix $$($(2)_SOURCE))) $$($(2)_DL_DIR)/$$($(2)_SOURCE) | \
$$(TAR) --strip-components=$$($(2)_STRIP_COMPONENTS) \
-C $$($(2)_DIR) \
$$(foreach x,$$($(2)_EXCLUDES),--exclude='$$(x)' ) \
$$(TAR_OPTIONS) -)
# pre/post-steps hooks
$(2)_PRE_DOWNLOAD_HOOKS ?=
$(2)_POST_DOWNLOAD_HOOKS ?=
$(2)_PRE_EXTRACT_HOOKS ?=
$(2)_POST_EXTRACT_HOOKS ?=
$(2)_PRE_RSYNC_HOOKS ?=
$(2)_POST_RSYNC_HOOKS ?=
$(2)_PRE_PATCH_HOOKS ?=
$(2)_POST_PATCH_HOOKS ?=
$(2)_PRE_CONFIGURE_HOOKS ?=
$(2)_POST_CONFIGURE_HOOKS ?=
$(2)_PRE_BUILD_HOOKS ?=
$(2)_POST_BUILD_HOOKS ?=
$(2)_PRE_INSTALL_HOOKS ?=
$(2)_POST_INSTALL_HOOKS ?=
$(2)_PRE_INSTALL_STAGING_HOOKS ?=
$(2)_POST_INSTALL_STAGING_HOOKS ?=
$(2)_PRE_INSTALL_TARGET_HOOKS ?=
$(2)_POST_INSTALL_TARGET_HOOKS ?=
$(2)_PRE_INSTALL_IMAGES_HOOKS ?=
$(2)_POST_INSTALL_IMAGES_HOOKS ?=
$(2)_PRE_LEGAL_INFO_HOOKS ?=
$(2)_POST_LEGAL_INFO_HOOKS ?=
$(2)_TARGET_FINALIZE_HOOKS ?=
fs: add pre- and post-command hooks In some cases, the directory structure we want in the filesystem is not exactly what we have in target/ For example, when systemd is used on a read-only rootfs, /var must be a tmpfs. However, we may have packages that install stuff in there, and set important rights (via the permission-table). So, at build time, we need /var to be a symlink to the remanent location (/usr/share/factory) while at runtime we need /var to be a directory. One option would have been to have /var as a real directory even during build time, and in a target-finalize hook, move everything out of there and into the "factory" location. However, that's not possible because it's too early: some packages may want to set ownership and/or acces rights on directories or files in /var, and this is only done in the fakeroot script, which is called only later during the assembling of the filesystem images. Also, there would have been no way to undo the tweak (i.e. we need to restore the /var symlink so that subsequent builds continue to work) if it were done as a target-finalize hook. The only solution is to allow packages to register pre- and post-hooks that are called right before and right after the rootfs commands are executed, and inside in the fakeroot script. We can however not re-use the BR2_ROOTFS_POST_FAKEROOT_SCRIPT feature either because it is done before the filesystem command, but there is nothing that is done after. Also, we don't want to add to, and modify a user-supplied variable. So, we introduce two new variables that packages can set to add the commands they need to run to tweak the filesystem right at the last moment. Those hooks are not documented on-purpose; they are probably going to only ever be used by systemd. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-01 16:52:22 -06:00
$(2)_ROOTFS_PRE_CMD_HOOKS ?=
ifeq ($$($(2)_TYPE),target)
ifneq ($$(HOST_$(2)_KCONFIG_VAR),)
$$(error "Package $(1) defines host variant before target variant!")
endif
endif
# human-friendly targets and target sequencing
$(1): $(1)-install
ifeq ($$($(2)_TYPE),host)
$(1)-install: $(1)-install-host
else
$(1)-install: $(1)-install-staging $(1)-install-target $(1)-install-images
endif
ifeq ($$($(2)_INSTALL_TARGET),YES)
$(1)-install-target: $$($(2)_TARGET_INSTALL_TARGET)
$$($(2)_TARGET_INSTALL_TARGET): $$($(2)_TARGET_BUILD)
else
$(1)-install-target:
endif
ifeq ($$($(2)_INSTALL_STAGING),YES)
$(1)-install-staging: $$($(2)_TARGET_INSTALL_STAGING)
$$($(2)_TARGET_INSTALL_STAGING): $$($(2)_TARGET_BUILD)
# Some packages use install-staging stuff for install-target
$$($(2)_TARGET_INSTALL_TARGET): $$($(2)_TARGET_INSTALL_STAGING)
else
$(1)-install-staging:
endif
ifeq ($$($(2)_INSTALL_IMAGES),YES)
$(1)-install-images: $$($(2)_TARGET_INSTALL_IMAGES)
$$($(2)_TARGET_INSTALL_IMAGES): $$($(2)_TARGET_BUILD)
else
$(1)-install-images:
endif
$(1)-install-host: $$($(2)_TARGET_INSTALL_HOST)
$$($(2)_TARGET_INSTALL_HOST): $$($(2)_TARGET_BUILD)
$(1)-build: $$($(2)_TARGET_BUILD)
$$($(2)_TARGET_BUILD): $$($(2)_TARGET_CONFIGURE)
# Since $(2)_FINAL_DEPENDENCIES are phony targets, they are always "newer"
# than $(2)_TARGET_CONFIGURE. This would force the configure step (and
# therefore the other steps as well) to be re-executed with every
# invocation of make. Therefore, make $(2)_FINAL_DEPENDENCIES an order-only
# dependency by using |.
$(1)-configure: $$($(2)_TARGET_CONFIGURE)
$$($(2)_TARGET_CONFIGURE): | $$($(2)_FINAL_DEPENDENCIES)
$$($(2)_TARGET_SOURCE) $$($(2)_TARGET_RSYNC): | prepare
$$($(2)_TARGET_SOURCE) $$($(2)_TARGET_RSYNC): | dependencies
ifeq ($$($(2)_OVERRIDE_SRCDIR),)
# In the normal case (no package override), the sequence of steps is
# source, by downloading
# depends
# extract
# patch
# configure
$$($(2)_TARGET_CONFIGURE): $$($(2)_TARGET_PATCH)
$(1)-patch: $$($(2)_TARGET_PATCH)
$$($(2)_TARGET_PATCH): $$($(2)_TARGET_EXTRACT)
# Order-only dependency
$$($(2)_TARGET_PATCH): | $$(patsubst %,%-patch,$$($(2)_FINAL_PATCH_DEPENDENCIES))
$(1)-extract: $$($(2)_TARGET_EXTRACT)
$$($(2)_TARGET_EXTRACT): $$($(2)_TARGET_SOURCE)
$$($(2)_TARGET_EXTRACT): | $$($(2)_FINAL_EXTRACT_DEPENDENCIES)
$(1)-depends: $$($(2)_FINAL_ALL_DEPENDENCIES)
$(1)-source: $$($(2)_TARGET_SOURCE)
$$($(2)_TARGET_SOURCE): | $$($(2)_FINAL_DOWNLOAD_DEPENDENCIES)
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(1)-all-source: $(1)-legal-source
$(1)-legal-info: $(1)-legal-source
$(1)-legal-source: $(1)-source
# Only download the actual source if it differs from the 'main' archive
ifneq ($$($(2)_ACTUAL_SOURCE_TARBALL),)
ifneq ($$($(2)_ACTUAL_SOURCE_TARBALL),$$($(2)_SOURCE))
$(1)-legal-source: $$($(2)_TARGET_ACTUAL_SOURCE)
endif # actual sources != sources
endif # actual sources != ""
$(1)-external-deps:
@for p in $$($(2)_SOURCE) $$($(2)_PATCH) $$($(2)_EXTRA_DOWNLOADS) ; do \
echo `basename $$$$p` ; \
done
else
# In the package override case, the sequence of steps
# source, by rsyncing
# depends
# configure
# Use an order-only dependency so the "<pkg>-clean-for-rebuild" rule
# can remove the stamp file without triggering the configure step.
$$($(2)_TARGET_CONFIGURE): | $$($(2)_TARGET_RSYNC)
$(1)-depends: $$($(2)_FINAL_DEPENDENCIES)
$(1)-patch: $(1)-rsync
$(1)-extract: $(1)-rsync
$(1)-rsync: $$($(2)_TARGET_RSYNC)
$(1)-source:
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(1)-legal-source:
$(1)-external-deps:
@echo "file://$$($(2)_OVERRIDE_SRCDIR)"
endif
$(1)-show-version:
@echo $$($(2)_VERSION)
$(1)-show-depends:
@echo $$($(2)_FINAL_ALL_DEPENDENCIES)
$(1)-show-recursive-depends:
infra/pkg-generic: use pure Makefile-based recursive dependencies Calling to the graph-depends script is very costly, as it calls back to 'make' a lot of time. It turns out that we already have the list of recursive dependencies, so we can just print that. As for the recursive reverse dependencies, we use the same memoisation technique to cut-down on the expansion cost, which would otherwise be on the order of 𝑶(𝑛²) (with 𝑛 enabled packages). >From a defconfig, modified to use glibc, C++, wchar, locales, ssp, and allyespackageconfig (tweaked to avoid multi providers, etc...), the timings for X-show-recursive-rdepends are: before after speedup #rdeps libnss 0m22.932s 0m5.775s 3.97x 3 qt5base 0m41.176s 0m5.781s 7.12x 67 libjpeg 0m56.185s 0m5.749s 9.71x 228 libxml2 0m54.964s 0m5.795s 9.48x 271 freetype 0m46.754s 0m5.819s 8.07x 287 libpng 0m53.577s 0m5.760s 9.30x 303 sqlite 1m15.222s 0m5.807s 12.95x 801 libopenssl 1m25.471s 0m5.844s 14.63x 931 readline 1m13.805s 0m5.775s 12.78x 958 libzlib 1m11.807s 0m5.820s 12.34x 1039 toolchain 1m23.712s 0m6.080s 13.77x 2107 skeleton 1m27.839s 0m6.293s 13.96x 2111 (+1) host-skeleton 1m27.405s 0m6.350s 13.76x 2172 (+2) - speedup: ratio before/after - #rdeps: number of recursive reverse dependencies, with the extra dependencies returned with this patch, see below for the reason. So, for a low-level package with a lot of reverse dependencies, like libzlibz, libopenssl or readline are, the timings are already very much in favour of the change. This is less impressive with packages that have few dependencies (libnss), but still much faster. Also, remember that the config tested has as much packages enabled as possible, so is in itself a degenerate case. With simpler and more realistic configurations, the gains would probably be a bit lower than reported above, but various tests still report good improvements overall (note: coming up with a 'realistic' configuration is pretty hard, as everyone and their dog have their notion of what is realistic in their context, so nothing displayed here; timings are left as an exercise for the interested parties to report aggravation in their cases should they notice some regression). Note that, more recursive reverse dependencies may be displayed now, since we do not apply the exceptions applied in graph-depends. For example, host-skeleton gains two new recursive reverse dependencies: skeleton and toolchain, which are both exceptions in graph-depends. As for direct (not reverse) dependencies: the gain is not as fantastic as for reverse ones, but it is still noticeable, especially thanks to a21212fb7cf (package/pkg-generic: speed up RECURSIVE_FINAL_DEPENDENCIES); just a few examples for %-show-recursive-depends: before after speedup #deps libzlib 0m46.864s 0m5.902s 7.94x 17 qt5base 0m57.590s 0m5.848s 9.85x 190 sqlite 0m46.601s 0m5.816s 8.01x 24 Basically, displaying recursive dependencies, direct or reverse, is almost a constant now: it only slightly varies by about 10% depending on the complexity of the dependency chain, with the parsing of the Makefiles still accounting for the large majority of the time. (PS. Thanks to Joseph for suggesting a list of interesting packages to test, and thanks to Trent for his example of memoisation!) 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: Joseph Kogut <joseph.kogut@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-03 03:16:34 -07:00
@echo $$($(2)_FINAL_RECURSIVE_DEPENDENCIES)
$(1)-show-rdepends:
@echo $$($(2)_RDEPENDENCIES)
$(1)-show-recursive-rdepends:
infra/pkg-generic: use pure Makefile-based recursive dependencies Calling to the graph-depends script is very costly, as it calls back to 'make' a lot of time. It turns out that we already have the list of recursive dependencies, so we can just print that. As for the recursive reverse dependencies, we use the same memoisation technique to cut-down on the expansion cost, which would otherwise be on the order of 𝑶(𝑛²) (with 𝑛 enabled packages). >From a defconfig, modified to use glibc, C++, wchar, locales, ssp, and allyespackageconfig (tweaked to avoid multi providers, etc...), the timings for X-show-recursive-rdepends are: before after speedup #rdeps libnss 0m22.932s 0m5.775s 3.97x 3 qt5base 0m41.176s 0m5.781s 7.12x 67 libjpeg 0m56.185s 0m5.749s 9.71x 228 libxml2 0m54.964s 0m5.795s 9.48x 271 freetype 0m46.754s 0m5.819s 8.07x 287 libpng 0m53.577s 0m5.760s 9.30x 303 sqlite 1m15.222s 0m5.807s 12.95x 801 libopenssl 1m25.471s 0m5.844s 14.63x 931 readline 1m13.805s 0m5.775s 12.78x 958 libzlib 1m11.807s 0m5.820s 12.34x 1039 toolchain 1m23.712s 0m6.080s 13.77x 2107 skeleton 1m27.839s 0m6.293s 13.96x 2111 (+1) host-skeleton 1m27.405s 0m6.350s 13.76x 2172 (+2) - speedup: ratio before/after - #rdeps: number of recursive reverse dependencies, with the extra dependencies returned with this patch, see below for the reason. So, for a low-level package with a lot of reverse dependencies, like libzlibz, libopenssl or readline are, the timings are already very much in favour of the change. This is less impressive with packages that have few dependencies (libnss), but still much faster. Also, remember that the config tested has as much packages enabled as possible, so is in itself a degenerate case. With simpler and more realistic configurations, the gains would probably be a bit lower than reported above, but various tests still report good improvements overall (note: coming up with a 'realistic' configuration is pretty hard, as everyone and their dog have their notion of what is realistic in their context, so nothing displayed here; timings are left as an exercise for the interested parties to report aggravation in their cases should they notice some regression). Note that, more recursive reverse dependencies may be displayed now, since we do not apply the exceptions applied in graph-depends. For example, host-skeleton gains two new recursive reverse dependencies: skeleton and toolchain, which are both exceptions in graph-depends. As for direct (not reverse) dependencies: the gain is not as fantastic as for reverse ones, but it is still noticeable, especially thanks to a21212fb7cf (package/pkg-generic: speed up RECURSIVE_FINAL_DEPENDENCIES); just a few examples for %-show-recursive-depends: before after speedup #deps libzlib 0m46.864s 0m5.902s 7.94x 17 qt5base 0m57.590s 0m5.848s 9.85x 190 sqlite 0m46.601s 0m5.816s 8.01x 24 Basically, displaying recursive dependencies, direct or reverse, is almost a constant now: it only slightly varies by about 10% depending on the complexity of the dependency chain, with the parsing of the Makefiles still accounting for the large majority of the time. (PS. Thanks to Joseph for suggesting a list of interesting packages to test, and thanks to Trent for his example of memoisation!) 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: Joseph Kogut <joseph.kogut@gmail.com> Cc: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-03 03:16:34 -07:00
@echo $$($(2)_FINAL_RECURSIVE_RDEPENDENCIES)
$(1)-show-build-order: $$(patsubst %,%-show-build-order,$$($(2)_FINAL_ALL_DEPENDENCIES))
@:
$$(info $(1))
$(1)-show-info:
@:
$$(info $$(call clean-json,{ $$(call json-info,$(2)) }))
$(1)-graph-depends: graph-depends-requirements
$(call pkg-graph-depends,$(1),--direct)
$(1)-graph-rdepends: graph-depends-requirements
$(call pkg-graph-depends,$(1),--reverse)
$(1)-all-source: $(1)-source
$(1)-all-source: $$(foreach p,$$($(2)_FINAL_ALL_DEPENDENCIES),$$(p)-all-source)
$(1)-all-external-deps: $(1)-external-deps
$(1)-all-external-deps: $$(foreach p,$$($(2)_FINAL_ALL_DEPENDENCIES),$$(p)-all-external-deps)
$(1)-all-legal-info: $(1)-legal-info
$(1)-all-legal-info: $$(foreach p,$$($(2)_FINAL_ALL_DEPENDENCIES),$$(p)-all-legal-info)
$(1)-dirclean: $$($(2)_TARGET_DIRCLEAN)
$(1)-clean-for-reinstall:
ifneq ($$($(2)_OVERRIDE_SRCDIR),)
rm -f $$($(2)_TARGET_RSYNC)
endif
rm -f $$($(2)_TARGET_INSTALL_STAGING)
rm -f $$($(2)_TARGET_INSTALL_TARGET)
rm -f $$($(2)_TARGET_INSTALL_IMAGES)
rm -f $$($(2)_TARGET_INSTALL_HOST)
$(1)-reinstall: $(1)-clean-for-reinstall $(1)
$(1)-clean-for-rebuild: $(1)-clean-for-reinstall
rm -f $$($(2)_TARGET_BUILD)
$(1)-rebuild: $(1)-clean-for-rebuild $(1)
$(1)-clean-for-reconfigure: $(1)-clean-for-rebuild
rm -f $$($(2)_TARGET_CONFIGURE)
$(1)-reconfigure: $(1)-clean-for-reconfigure $(1)
# define the PKG variable for all targets, containing the
# uppercase package variable prefix
$$($(2)_TARGET_INSTALL_TARGET): PKG=$(2)
$$($(2)_TARGET_INSTALL_STAGING): PKG=$(2)
$$($(2)_TARGET_INSTALL_IMAGES): PKG=$(2)
$$($(2)_TARGET_INSTALL_HOST): PKG=$(2)
$$($(2)_TARGET_BUILD): PKG=$(2)
$$($(2)_TARGET_CONFIGURE): PKG=$(2)
$$($(2)_TARGET_RSYNC): SRCDIR=$$($(2)_OVERRIDE_SRCDIR)
$$($(2)_TARGET_RSYNC): PKG=$(2)
$$($(2)_TARGET_PATCH): PKG=$(2)
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$$($(2)_TARGET_PATCH): RAWNAME=$$(patsubst host-%,%,$(1))
$$($(2)_TARGET_PATCH): PKGDIR=$(pkgdir)
$$($(2)_TARGET_EXTRACT): PKG=$(2)
$$($(2)_TARGET_SOURCE): PKG=$(2)
$$($(2)_TARGET_SOURCE): PKGDIR=$(pkgdir)
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$$($(2)_TARGET_ACTUAL_SOURCE): PKG=$(2)
$$($(2)_TARGET_ACTUAL_SOURCE): PKGDIR=$(pkgdir)
$$($(2)_TARGET_DIRCLEAN): PKG=$(2)
# Compute the name of the Kconfig option that correspond to the
# package being enabled. We handle three cases: the special Linux
# kernel case, the bootloaders case, and the normal packages case.
ifeq ($(1),linux)
$(2)_KCONFIG_VAR = BR2_LINUX_KERNEL
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 08:39:20 -06:00
else ifneq ($$(filter boot/% $$(foreach dir,$$(BR2_EXTERNAL_DIRS),$$(dir)/boot/%),$(pkgdir)),)
$(2)_KCONFIG_VAR = BR2_TARGET_$(2)
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 08:39:20 -06:00
else ifneq ($$(filter toolchain/% $$(foreach dir,$$(BR2_EXTERNAL_DIRS),$$(dir)/toolchain/%),$(pkgdir)),)
$(2)_KCONFIG_VAR = BR2_$(2)
else
$(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
endif
# legal-info: declare dependencies and set values used later for the manifest
ifneq ($$($(2)_LICENSE_FILES),)
$(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
endif
core/legal-info: also save patches Currently, the legal-info infra only saves the source archive of a package. However, that's not enough as we may apply some patches on packages sources. We do suggest users to also redistribute the Buildroot sources as part of their compliance distribution, so the patches bundled in Buildroot would indeed be included in the compliance distribution. However, that's still not enough, since we may download some patches, or the user may use a global patch directory. Patches in there might not end up in the compliance distribution, and there are risks of non-conformity. So, always include patches alongside the source archive. To ensure reproducibility, we also generate a series file, so patches can be re-applied in the correct order. We get the list of patches to include from the list of patches that were applied by the package infrastructure (via the apply-patches support script). So, we need to get packages properly extracted and patched before we can save their legal-info, not just in the case they define _LICENSE_FILES. Update the legal-info header accordingly. Note: this means that, when a package is not patched and defines no LICENSE_FILES, we will extract and patch it for nothing. There is no easy way to know whether we have to patch a package or not. We can only either duplicate the logic to detect patches (bad) or rely on the infra actually patching the package. Also, a vast majority of packages are either patched, or define _LICENSE_FILES, so it is best and easiest to always extract and patch them prior to legal-info. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:33 -06:00
# We need to extract and patch a package to be able to retrieve its
# license files (if any) and the list of patches applied to it (if
# any).
$(1)-legal-info: $(1)-patch
2014-06-22 06:41:12 -06:00
# We only save the sources of packages we want to redistribute, that are
# non-overriden (local or true override).
ifeq ($$($(2)_REDISTRIBUTE),YES)
ifeq ($$($(2)_OVERRIDE_SRCDIR),)
2014-06-22 06:41:12 -06:00
# Packages that have a tarball need it downloaded beforehand
$(1)-legal-info: $(1)-source $$(REDIST_SOURCES_DIR_$$(call UPPERCASE,$(4)))
endif
endif
# legal-info: produce legally relevant info.
$(1)-legal-info: PKG=$(2)
$(1)-legal-info:
@$$(call MESSAGE,"Collecting legal info")
# Packages without a source are assumed to be part of Buildroot, skip them.
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
$$(foreach hook,$$($(2)_PRE_LEGAL_INFO_HOOKS),$$(call $$(hook))$$(sep))
ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
# Save license files if defined
# We save the license files for any kind of package: normal, local,
# overridden, or non-redistributable alike.
# The reason to save license files even for no-redistribute packages
# is that the license still applies to the files distributed as part
# of the rootfs, even if the sources are not themselves redistributed.
ifeq ($$(call qstrip,$$($(2)_LICENSE_FILES)),)
core: rename FOO_BASE_NAME to FOO_BASENAME to avoid clashes In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-02-06 05:59:23 -07:00
$(Q)$$(call legal-warning-pkg,$$($(2)_BASENAME_RAW),cannot save license ($(2)_LICENSE_FILES not defined))
else
$(Q)$$(foreach F,$$($(2)_LICENSE_FILES),$$(call legal-license-file,$$($(2)_RAWNAME),$$($(2)_BASENAME_RAW),$$($(2)_HASH_FILE),$$(F),$$($(2)_DIR)/$$(F),$$(call UPPERCASE,$(4)))$$(sep))
endif # license files
ifeq ($$($(2)_SITE_METHOD),local)
# Packages without a tarball: don't save and warn
@$$(call legal-warning-nosource,$$($(2)_RAWNAME),local)
else ifneq ($$($(2)_OVERRIDE_SRCDIR),)
@$$(call legal-warning-nosource,$$($(2)_RAWNAME),override)
else
# Other packages
ifeq ($$($(2)_REDISTRIBUTE),YES)
# Save the source tarball and any extra downloads, but not
# patches, as they are handled specially afterwards.
$$(foreach e,$$($(2)_ACTUAL_SOURCE_TARBALL) $$(notdir $$($(2)_EXTRA_DOWNLOADS)),\
$$(Q)support/scripts/hardlink-or-copy \
$$($(2)_DL_DIR)/$$(e) \
$$($(2)_REDIST_SOURCES_DIR)$$(sep))
core/legal-info: also save patches Currently, the legal-info infra only saves the source archive of a package. However, that's not enough as we may apply some patches on packages sources. We do suggest users to also redistribute the Buildroot sources as part of their compliance distribution, so the patches bundled in Buildroot would indeed be included in the compliance distribution. However, that's still not enough, since we may download some patches, or the user may use a global patch directory. Patches in there might not end up in the compliance distribution, and there are risks of non-conformity. So, always include patches alongside the source archive. To ensure reproducibility, we also generate a series file, so patches can be re-applied in the correct order. We get the list of patches to include from the list of patches that were applied by the package infrastructure (via the apply-patches support script). So, we need to get packages properly extracted and patched before we can save their legal-info, not just in the case they define _LICENSE_FILES. Update the legal-info header accordingly. Note: this means that, when a package is not patched and defines no LICENSE_FILES, we will extract and patch it for nothing. There is no easy way to know whether we have to patch a package or not. We can only either duplicate the logic to detect patches (bad) or rely on the infra actually patching the package. Also, a vast majority of packages are either patched, or define _LICENSE_FILES, so it is best and easiest to always extract and patch them prior to legal-info. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:33 -06:00
# Save patches and generate the series file
$$(Q)while read f; do \
support/scripts/hardlink-or-copy \
$$$${f} \
$$($(2)_REDIST_SOURCES_DIR) || exit 1; \
printf "%s\n" "$$$${f##*/}" >>$$($(2)_REDIST_SOURCES_DIR)/series || exit 1; \
done <$$($(2)_DIR)/.applied_patches_list
endif # redistribute
endif # other packages
@$$(call legal-manifest,$$(call UPPERCASE,$(4)),$$($(2)_RAWNAME),$$($(2)_VERSION),$$(subst $$(space)$$(comma),$$(comma),$$($(2)_LICENSE)),$$($(2)_MANIFEST_LICENSE_FILES),$$($(2)_ACTUAL_SOURCE_TARBALL),$$($(2)_ACTUAL_SOURCE_SITE),$$(call legal-deps,$(1)))
infra: consistently use double dollar signs inside inner-xxx-targets The inner-xxx-targets in the buildroot package infrastructures are evaluated using $(eval) which causes variable references to be a bit different than in regular make code. As we want most references to be expanded only at the time of the $(eval) we should not use standard references $(VAR) but rather use double dollar signs $$(VAR). This includes function references like $(call), $(subst), etc. The only exception is the reference to pkgdir/pkgname and numbered variables, which are parameters to the inner block: $(1), $(2), etc. This patch introduces consistent usage of double-dollar signs throughout the different inner-xxx-targets blocks. In some cases, this would potentially cause circular references, in particular when the value of HOST_FOO_VAR would be obtained from the corresponding FOO_VAR if HOST_FOO_VAR is not defined. In these cases, a test is added to check for a host package (the only case where such constructions are relevant; these are not circular). Benefits of these changes are: - behavior of variables is now again as expected. For example, setting $(2)_VERSION = virtual in pkg-virtual.mk will effectively work, while originally it would cause very odd results. - The output of 'make printvars' is now much more useful. This target shows the value of all variables, and the expression that led to that value. However, if the expression was coming from an inner-xxx-targets block, and was using single dollar signs, it would show in printvars as VAR = value (value) while if double dollar signs are used, it would effectively look like VAR = value (actual expression) as is intended. This improvement is for example effective for FOO_DL_VERSION, FOO_RAWNAME, FOO_SITE_METHOD and FOO_MAKE. The correctness of this patch has been verified using 'make printvars', 'make manual' and 'make legal-info' before and after applying this patch, and comparing the output. Insight-provided-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-11 13:12:24 -06:00
endif # ifneq ($$(call qstrip,$$($(2)_SOURCE)),)
$$(foreach hook,$$($(2)_POST_LEGAL_INFO_HOOKS),$$(call $$(hook))$$(sep))
# add package to the general list of targets if requested by the buildroot
# configuration
ifeq ($$($$($(2)_KCONFIG_VAR)),y)
infra/pkg-virtual: validate only one provider provides an implementation Currently, it is possible that more than one provider of a virtual package is selected in the menuconfig. This leads to autobuild failures, and we do not protect the user from making a mistake in the configuration. The failure is then hard to troubleshoot in any case. We can't use kconfig constructs to prevent this, since kconfig does not tell how many options did a select on another option. This change introduces a new variable a provider *must* define to include all the virtual packages it is an implementation of. Then, when evaluating the package's rules, we check that the provider is indeed the declared one for each virtual package it claims to be an implementation of. This works by taking advantage that when more than one provider is selected, only one of them will 'win' in setting the _PROVIDES_FOO option. Thus any provider just has to check it is indeed the declared provider. If not, it means that one or more other provider is selected. This gives the opportunity to the user to change its configuration, and we can match the error message in the autobuilders to skip those failures (we can skip them instead of reporting them, since they are obviously configuration errors that should not happen in the first place.) [Note: kudos to Arnout for suggesting this actual implementation. :-)] Fixes: http://autobuild.buildroot.org/results/285/2851069d6964aa46d26b4aabe7d84e8c0c6c72ce http://autobuild.buildroot.net/results/9b7/9b7870354d70e27e42d3d9c1f131ab54706bf20e [...] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-15 11:37:03 -06:00
# Ensure the calling package is the declared provider for all the virtual
# packages it claims to be an implementation of.
ifneq ($$($(2)_PROVIDES),)
$$(foreach pkg,$$($(2)_PROVIDES),\
$$(eval $$(call virt-provides-single,$$(pkg),$$(call UPPERCASE,$$(pkg)),$(1))$$(sep)))
endif
# Register package as a reverse-dependencies of all its dependencies
$$(eval $$(foreach p,$$($(2)_FINAL_ALL_DEPENDENCIES),\
$$(call UPPERCASE,$$(p))_RDEPENDENCIES += $(1)$$(sep)))
# Ensure unified variable name conventions between all packages Some
# of the variables are used by more than one infrastructure; so,
# rather than duplicating the checks in each infrastructure, we check
# all variables here in pkg-generic, even though pkg-generic should
# have no knowledge of infra-specific variables.
$(eval $(call check-deprecated-variable,$(2)_MAKE_OPT,$(2)_MAKE_OPTS))
$(eval $(call check-deprecated-variable,$(2)_INSTALL_OPT,$(2)_INSTALL_OPTS))
$(eval $(call check-deprecated-variable,$(2)_INSTALL_TARGET_OPT,$(2)_INSTALL_TARGET_OPTS))
$(eval $(call check-deprecated-variable,$(2)_INSTALL_STAGING_OPT,$(2)_INSTALL_STAGING_OPTS))
$(eval $(call check-deprecated-variable,$(2)_INSTALL_HOST_OPT,$(2)_INSTALL_HOST_OPTS))
$(eval $(call check-deprecated-variable,$(2)_AUTORECONF_OPT,$(2)_AUTORECONF_OPTS))
$(eval $(call check-deprecated-variable,$(2)_CONF_OPT,$(2)_CONF_OPTS))
$(eval $(call check-deprecated-variable,$(2)_BUILD_OPT,$(2)_BUILD_OPTS))
$(eval $(call check-deprecated-variable,$(2)_GETTEXTIZE_OPT,$(2)_GETTEXTIZE_OPTS))
$(eval $(call check-deprecated-variable,$(2)_KCONFIG_OPT,$(2)_KCONFIG_OPTS))
PACKAGES += $(1)
ifneq ($$($(2)_PERMISSIONS),)
PACKAGES_PERMISSIONS_TABLE += $$($(2)_PERMISSIONS)$$(sep)
endif
ifneq ($$($(2)_DEVICES),)
PACKAGES_DEVICES_TABLE += $$($(2)_DEVICES)$$(sep)
endif
ifneq ($$($(2)_USERS),)
PACKAGES_USERS += $$($(2)_USERS)$$(sep)
endif
TARGET_FINALIZE_HOOKS += $$($(2)_TARGET_FINALIZE_HOOKS)
fs: add pre- and post-command hooks In some cases, the directory structure we want in the filesystem is not exactly what we have in target/ For example, when systemd is used on a read-only rootfs, /var must be a tmpfs. However, we may have packages that install stuff in there, and set important rights (via the permission-table). So, at build time, we need /var to be a symlink to the remanent location (/usr/share/factory) while at runtime we need /var to be a directory. One option would have been to have /var as a real directory even during build time, and in a target-finalize hook, move everything out of there and into the "factory" location. However, that's not possible because it's too early: some packages may want to set ownership and/or acces rights on directories or files in /var, and this is only done in the fakeroot script, which is called only later during the assembling of the filesystem images. Also, there would have been no way to undo the tweak (i.e. we need to restore the /var symlink so that subsequent builds continue to work) if it were done as a target-finalize hook. The only solution is to allow packages to register pre- and post-hooks that are called right before and right after the rootfs commands are executed, and inside in the fakeroot script. We can however not re-use the BR2_ROOTFS_POST_FAKEROOT_SCRIPT feature either because it is done before the filesystem command, but there is nothing that is done after. Also, we don't want to add to, and modify a user-supplied variable. So, we introduce two new variables that packages can set to add the commands they need to run to tweak the filesystem right at the last moment. Those hooks are not documented on-purpose; they are probably going to only ever be used by systemd. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-01 16:52:22 -06:00
ROOTFS_PRE_CMD_HOOKS += $$($(2)_ROOTFS_PRE_CMD_HOOKS)
ifeq ($$($(2)_SITE_METHOD),svn)
DL_TOOLS_DEPENDENCIES += svn
else ifeq ($$($(2)_SITE_METHOD),git)
DL_TOOLS_DEPENDENCIES += git
else ifeq ($$($(2)_SITE_METHOD),bzr)
DL_TOOLS_DEPENDENCIES += bzr
else ifeq ($$($(2)_SITE_METHOD),scp)
DL_TOOLS_DEPENDENCIES += scp ssh
else ifeq ($$($(2)_SITE_METHOD),hg)
DL_TOOLS_DEPENDENCIES += hg
else ifeq ($$($(2)_SITE_METHOD),cvs)
DL_TOOLS_DEPENDENCIES += cvs
endif # SITE_METHOD
DL_TOOLS_DEPENDENCIES += $$(call extractor-dependency,$$($(2)_SOURCE))
# Ensure all virtual targets are PHONY. Listed alphabetically.
.PHONY: $(1) \
$(1)-all-external-deps \
$(1)-all-legal-info \
$(1)-all-source \
$(1)-build \
$(1)-clean-for-rebuild \
$(1)-clean-for-reconfigure \
$(1)-clean-for-reinstall \
$(1)-configure \
$(1)-depends \
$(1)-dirclean \
$(1)-external-deps \
$(1)-extract \
$(1)-graph-depends \
$(1)-graph-rdepends \
$(1)-install \
$(1)-install-host \
$(1)-install-images \
$(1)-install-staging \
$(1)-install-target \
$(1)-legal-info \
core/legal-info: ensure legal-info works in off-line mode Almost all packages which are saved for legal-info have their source archives downloaded as part of 'make source', which makes an off-line build completely possible [0]. However, for the pre-configured external toolchains, the source tarball is different, as the main tarball is a binary package. And that source tarball is only downloaded during the legal-info phase, which makes it inconvenient for full off-line builds. We fix that by adding a new rule, $(1)-legal-source which only $(1)-all-source depends on, so that we only download it for a top-level 'make source', not as part of the standard download mechanism (i.e. only what is really needed to build). This new rule depends, like the normal download mechanism, on a stamp file, so that we do not emit a spurious hash-check message on successive runs of 'make source'. This way, we can do a complete [0] off-line build and are still able to generate legal-info, while at the same time we do not incur any download overhead during a simple build. Also, we previously downloaded the _ACTUAL_SOURCE_TARBALL when it was not empty. However, since _ACTUAL_SOURCE_TARBALL defaults to the value of _SOURCE, it can not be empty when _SOURCE is not. Thus, we'd get a spurious report of a missing hash for the tarball, since it was not in a standard package rule (configure, build, install..) and thus would miss the PKG and PKGDIR variables to find the .hash file. We fix that in this commit as well, by: - setting PKG and PKGDIR just for the -legal-source rule; - only downloading _ACTUAL_SOURCE_TARBALL if it is not empty *and* not the same as _SOURCE (to avoid a second report about the hash). [0] Save for nodejs which invarriably wants to download stuff at build time. Sigh... :-( Fixing that is work for another time... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 10:14:38 -06:00
$(1)-legal-source \
$(1)-patch \
$(1)-rebuild \
$(1)-reconfigure \
$(1)-reinstall \
$(1)-rsync \
$(1)-show-depends \
$(1)-show-info \
$(1)-show-version \
$(1)-source
ifneq ($$($(2)_SOURCE),)
ifeq ($$($(2)_SITE),)
$$(error $(2)_SITE cannot be empty when $(2)_SOURCE is not)
endif
endif
pkg-generic: prevent _SITE URLs with a trailing slash A trailing slash in FOO_SITE is useless, since Buildroot automatically adds a slash between FOO_SITE and the filename as appropriate. Moreover it is potentially harmful, which led to introducing a workaround to strip them: commit 1cbffbd015106ea90fe49e27433375769dc1035b Author: Shawn J. Goff <shawn7400@gmail.com> Date: Fri Apr 12 09:40:30 2013 +0000 eliminate double slashes caused by FOO_SITE ending in a slash When a FOO_SITE variable ends in a slash and gets joined with a FOO_SOURCE variable like $(FOO_SITE)/$(FOO_SOURCE), the resulting URI has a double slash. While double-slashes are fine in unix paths, they are reserved in URIs - the part following '//' must be an authority. So let's ban trailing slashes entirely. They have all been removed in a 7b0e757fb85fd, now add a check to error out loudly in case a new one is added. Example commands to test this check: $ make busybox-dirclean busybox-source rm -Rf /home/murray/devel/buildroot/output/build/busybox-1.23.2 busybox-1.23.2.tar.bz2: OK (md5: 7925683d7dd105aabe9b6b618d48cc73) busybox-1.23.2.tar.bz2: OK (sha1: 7f37193cb249f27630e0b2a2c6c9bbb7b1d24c16) $ $ make BUSYBOX_SITE=http://www.busybox.net/downloads/ busybox-dirclean busybox-source rm -Rf /home/murray/devel/buildroot/output/build/busybox-1.23.2 BUSYBOX_SITE (http://www.busybox.net/downloads/) cannot have a trailing slash make[1]: *** [/home/murray/devel/buildroot/output/build/busybox-1.23.2/.stamp_downloaded] Error 1 make: *** [_all] Error 2 $ Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-03 11:22:17 -06:00
ifeq ($$(patsubst %/,ERROR,$$($(2)_SITE)),ERROR)
$$(error $(2)_SITE ($$($(2)_SITE)) cannot have a trailing slash)
endif
ifneq ($$($(2)_HELP_CMDS),)
HELP_PACKAGES += $(2)
endif
endif # $(2)_KCONFIG_VAR
endef # inner-generic-package
################################################################################
# generic-package -- the target generator macro for generic packages
################################################################################
# In the case of target packages, keep the package name "pkg"
generic-package = $(call inner-generic-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
# In the case of host packages, turn the package name "pkg" into "host-pkg"
host-generic-package = $(call inner-generic-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)
# :mode=makefile: