buildroot/package/pkg-autotools.mk

333 lines
9.9 KiB
Makefile
Raw Normal View History

################################################################################
# Autotools package infrastructure
#
# This file implements an infrastructure that eases development of
# package .mk files for autotools packages. It should be used for all
# packages that use the autotools as their build system.
#
# See the Buildroot documentation for details on the usage of this
# infrastructure
#
# In terms of implementation, this autotools infrastructure requires
# the .mk file to only specify metadata information about the
# package: name, version, download URL, etc.
#
# We still allow the package .mk file to override what the different
# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
# already defined, it is used as the list of commands to perform to
# build the package, instead of the default autotools behaviour. The
# package can also define some post operation hooks.
#
################################################################################
#
# Utility function to upgrade config.sub and config.guess files
#
# argument 1 : directory into which config.guess and config.sub need
# to be updated. Note that config.sub and config.guess are searched
# recursively in this directory.
#
define CONFIG_UPDATE
for file in config.guess config.sub; do \
for i in $$(find $(1) -name $$file); do \
cp support/gnuconfig/$$file $$i; \
done; \
done
endef
# This function generates the ac_cv_file_<foo> value for a given
# filename. This is needed to convince configure script doing
# AC_CHECK_FILE() tests that the file actually exists, since such
# tests cannot be done in a cross-compilation context. This function
# takes as argument the path of the file. An example usage is:
#
# FOOBAR_CONF_ENV = \
# $(call AUTOCONF_AC_CHECK_FILE_VAL,/dev/random)=yes
AUTOCONF_AC_CHECK_FILE_VAL = ac_cv_file_$(subst -,_,$(subst /,_,$(subst .,_,$(1))))
#
# Hook to update config.sub and config.guess if needed
#
define UPDATE_CONFIG_HOOK
@$(call MESSAGE,"Updating config.sub and config.guess")
$(call CONFIG_UPDATE,$(@D))
endef
#
# Hook to patch libtool to make it work properly for cross-compilation
#
define LIBTOOL_PATCH_HOOK
@$(call MESSAGE,"Patching libtool")
$(Q)for i in `find $($(PKG)_DIR) -name ltmain.sh`; do \
ltmain_version=`sed -n '/^[ \t]*VERSION=/{s/^[ \t]*VERSION=//;p;q;}' $$i | \
sed -e 's/\([0-9]*\.[0-9]*\).*/\1/' -e 's/\"//'`; \
ltmain_patchlevel=`sed -n '/^[ \t]*VERSION=/{s/^[ \t]*VERSION=//;p;q;}' $$i | \
sed -e 's/\([0-9]*\.[0-9]*\.*\)\([0-9]*\).*/\2/' -e 's/\"//'`; \
if test $${ltmain_version} = '1.5'; then \
core/pkg-autotools: don't use APPLY_PATCHES for libtool patches Since [1] <package>-reconfigure target is broken. $ make elementary-reconfigure Applying buildroot-libtool-v2.4.4.patch using patch: Error: duplicate filename 'buildroot-libtool-v2.4.4.patch' Conflicting files are: already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch When a package uses AUTORECONF, the libtool patch can be applied a second time on the same ltmain.sh in the same directory as the <package>-reconfigure target is called. This is not a problem since autoreconf will overwrite the previously patched files. But with the check introduced by [1], apply-patches.sh throw an error when the package is reconfigured since the libtool patch is already present in .applied_patches_list. In addition to this, the .applied_patches_list file generated by apply-patches.sh while patching ltmain.sh is not in the top-level package source directory. Instead a duplicated .applied_patches_list is generated beside the patched ltmain.sh which can be in a subdirectory. As noticed by Arnout Vandecappelle [2], the apply-patches.sh script doesn't bring anything for the libtool patches. "apply_patches.sh does the following: * It handles directories -> not needed here. * It handles compressed patches and tarballs -> not needed. * It handles series files -> not needed. * It handles errors in case of multiple patches -> not needed since it's only one patch. * It detects errors based on *.rej files -> not needed since it's only a single patch so patch exit code is OK. * It writes the patch list -> for libtool, this is quite silly because it will be written in the directory where ltmain.sh is found, not in the top-level directory, so you have these patch lists spread over the source tree." So use patch directly rather than apply-patches. [1] 19241598147e7555dce40b6dd44b28ef22b67ed9 [2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-17 10:01:08 -06:00
patch -i support/libtool/buildroot-libtool-v1.5.patch $${i}; \
elif test $${ltmain_version} = "2.2"; then\
core/pkg-autotools: don't use APPLY_PATCHES for libtool patches Since [1] <package>-reconfigure target is broken. $ make elementary-reconfigure Applying buildroot-libtool-v2.4.4.patch using patch: Error: duplicate filename 'buildroot-libtool-v2.4.4.patch' Conflicting files are: already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch When a package uses AUTORECONF, the libtool patch can be applied a second time on the same ltmain.sh in the same directory as the <package>-reconfigure target is called. This is not a problem since autoreconf will overwrite the previously patched files. But with the check introduced by [1], apply-patches.sh throw an error when the package is reconfigured since the libtool patch is already present in .applied_patches_list. In addition to this, the .applied_patches_list file generated by apply-patches.sh while patching ltmain.sh is not in the top-level package source directory. Instead a duplicated .applied_patches_list is generated beside the patched ltmain.sh which can be in a subdirectory. As noticed by Arnout Vandecappelle [2], the apply-patches.sh script doesn't bring anything for the libtool patches. "apply_patches.sh does the following: * It handles directories -> not needed here. * It handles compressed patches and tarballs -> not needed. * It handles series files -> not needed. * It handles errors in case of multiple patches -> not needed since it's only one patch. * It detects errors based on *.rej files -> not needed since it's only a single patch so patch exit code is OK. * It writes the patch list -> for libtool, this is quite silly because it will be written in the directory where ltmain.sh is found, not in the top-level directory, so you have these patch lists spread over the source tree." So use patch directly rather than apply-patches. [1] 19241598147e7555dce40b6dd44b28ef22b67ed9 [2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-17 10:01:08 -06:00
patch -i support/libtool/buildroot-libtool-v2.2.patch $${i}; \
elif test $${ltmain_version} = "2.4"; then\
if test $${ltmain_patchlevel:-0} -gt 2; then\
core/pkg-autotools: don't use APPLY_PATCHES for libtool patches Since [1] <package>-reconfigure target is broken. $ make elementary-reconfigure Applying buildroot-libtool-v2.4.4.patch using patch: Error: duplicate filename 'buildroot-libtool-v2.4.4.patch' Conflicting files are: already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch When a package uses AUTORECONF, the libtool patch can be applied a second time on the same ltmain.sh in the same directory as the <package>-reconfigure target is called. This is not a problem since autoreconf will overwrite the previously patched files. But with the check introduced by [1], apply-patches.sh throw an error when the package is reconfigured since the libtool patch is already present in .applied_patches_list. In addition to this, the .applied_patches_list file generated by apply-patches.sh while patching ltmain.sh is not in the top-level package source directory. Instead a duplicated .applied_patches_list is generated beside the patched ltmain.sh which can be in a subdirectory. As noticed by Arnout Vandecappelle [2], the apply-patches.sh script doesn't bring anything for the libtool patches. "apply_patches.sh does the following: * It handles directories -> not needed here. * It handles compressed patches and tarballs -> not needed. * It handles series files -> not needed. * It handles errors in case of multiple patches -> not needed since it's only one patch. * It detects errors based on *.rej files -> not needed since it's only a single patch so patch exit code is OK. * It writes the patch list -> for libtool, this is quite silly because it will be written in the directory where ltmain.sh is found, not in the top-level directory, so you have these patch lists spread over the source tree." So use patch directly rather than apply-patches. [1] 19241598147e7555dce40b6dd44b28ef22b67ed9 [2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-17 10:01:08 -06:00
patch -i support/libtool/buildroot-libtool-v2.4.4.patch $${i}; \
else \
core/pkg-autotools: don't use APPLY_PATCHES for libtool patches Since [1] <package>-reconfigure target is broken. $ make elementary-reconfigure Applying buildroot-libtool-v2.4.4.patch using patch: Error: duplicate filename 'buildroot-libtool-v2.4.4.patch' Conflicting files are: already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch When a package uses AUTORECONF, the libtool patch can be applied a second time on the same ltmain.sh in the same directory as the <package>-reconfigure target is called. This is not a problem since autoreconf will overwrite the previously patched files. But with the check introduced by [1], apply-patches.sh throw an error when the package is reconfigured since the libtool patch is already present in .applied_patches_list. In addition to this, the .applied_patches_list file generated by apply-patches.sh while patching ltmain.sh is not in the top-level package source directory. Instead a duplicated .applied_patches_list is generated beside the patched ltmain.sh which can be in a subdirectory. As noticed by Arnout Vandecappelle [2], the apply-patches.sh script doesn't bring anything for the libtool patches. "apply_patches.sh does the following: * It handles directories -> not needed here. * It handles compressed patches and tarballs -> not needed. * It handles series files -> not needed. * It handles errors in case of multiple patches -> not needed since it's only one patch. * It detects errors based on *.rej files -> not needed since it's only a single patch so patch exit code is OK. * It writes the patch list -> for libtool, this is quite silly because it will be written in the directory where ltmain.sh is found, not in the top-level directory, so you have these patch lists spread over the source tree." So use patch directly rather than apply-patches. [1] 19241598147e7555dce40b6dd44b28ef22b67ed9 [2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html Signed-off-by: Romain Naour <romain.naour@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-17 10:01:08 -06:00
patch -i support/libtool/buildroot-libtool-v2.4.patch $${i}; \
fi \
fi \
done
endef
#
# Hook to patch common issue with configure on powerpc64{,le} failing
# to detect shared library support:
#
define CONFIGURE_FIX_POWERPC64_HOOK
@$(call MESSAGE,"Checking configure (powerpc64/powerpc64le)")
support/scripts/fix-configure-powerpc64.sh $($(PKG)_DIR)
endef
#
# Hook to gettextize the package if needed
#
define GETTEXTIZE_HOOK
@$(call MESSAGE,"Gettextizing")
$(Q)cd $($(PKG)_SRCDIR) && $(GETTEXTIZE) $($(PKG)_GETTEXTIZE_OPTS)
endef
#
# Hook to autoreconf the package if needed
#
define AUTORECONF_HOOK
@$(call MESSAGE,"Autoreconfiguring")
$(Q)cd $($(PKG)_SRCDIR) && $($(PKG)_AUTORECONF_ENV) $(AUTORECONF) $($(PKG)_AUTORECONF_OPTS)
endef
################################################################################
# inner-autotools-package -- defines how the configuration, compilation and
# installation of an autotools package should be done, implements a
# few hooks to tune the build process for autotools specifities and
# calls the generic package infrastructure to generate the necessary
# make targets
#
# 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)
################################################################################
define inner-autotools-package
ifndef $(2)_LIBTOOL_PATCH
ifdef $(3)_LIBTOOL_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)_LIBTOOL_PATCH = $$($(3)_LIBTOOL_PATCH)
else
$(2)_LIBTOOL_PATCH ?= YES
endif
endif
ifndef $(2)_MAKE
ifdef $(3)_MAKE
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)_MAKE = $$($(3)_MAKE)
else
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)_MAKE ?= $$(MAKE)
endif
endif
ifndef $(2)_AUTORECONF
ifdef $(3)_AUTORECONF
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)_AUTORECONF = $$($(3)_AUTORECONF)
else
$(2)_AUTORECONF ?= NO
endif
endif
ifndef $(2)_GETTEXTIZE
ifdef $(3)_GETTEXTIZE
$(2)_GETTEXTIZE = $$($(3)_GETTEXTIZE)
else
$(2)_GETTEXTIZE ?= NO
endif
endif
ifeq ($(4),host)
$(2)_GETTEXTIZE_OPTS ?= $$($(3)_GETTEXTIZE_OPTS)
endif
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
ifeq ($(4),host)
$(2)_AUTORECONF_OPTS ?= $$($(3)_AUTORECONF_OPTS)
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
$(2)_CONF_ENV ?=
$(2)_CONF_OPTS ?=
$(2)_MAKE_ENV ?=
$(2)_MAKE_OPTS ?=
$(2)_INSTALL_OPTS ?= install
$(2)_INSTALL_STAGING_OPTS ?= DESTDIR=$$(STAGING_DIR) install
$(2)_INSTALL_TARGET_OPTS ?= DESTDIR=$$(TARGET_DIR) install
#
# Configure step. Only define it if not already defined by the package
# .mk file. And take care of the differences between host and target
# packages.
#
ifndef $(2)_CONFIGURE_CMDS
ifeq ($(4),target)
# Configure package for target
define $(2)_CONFIGURE_CMDS
(cd $$($$(PKG)_SRCDIR) && rm -rf config.cache && \
$$(TARGET_CONFIGURE_OPTS) \
$$(TARGET_CONFIGURE_ARGS) \
$$($$(PKG)_CONF_ENV) \
CONFIG_SITE=/dev/null \
./configure \
--target=$$(GNU_TARGET_NAME) \
--host=$$(GNU_TARGET_NAME) \
--build=$$(GNU_HOST_NAME) \
--prefix=/usr \
--exec-prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--program-prefix="" \
--disable-gtk-doc \
--disable-gtk-doc-html \
--disable-doc \
--disable-docs \
--disable-documentation \
--with-xmlto=no \
--with-fop=no \
$$(if $$($$(PKG)_OVERRIDE_SRCDIR),,--disable-dependency-tracking) \
--enable-ipv6 \
$$(NLS_OPTS) \
$$(SHARED_STATIC_LIBS_OPTS) \
$$(QUIET) $$($$(PKG)_CONF_OPTS) \
)
endef
else
# Configure package for host
# disable all kind of documentation generation in the process,
# because it often relies on host tools which may or may not be
# installed.
define $(2)_CONFIGURE_CMDS
(cd $$($$(PKG)_SRCDIR) && rm -rf config.cache; \
$$(HOST_CONFIGURE_OPTS) \
CFLAGS="$$(HOST_CFLAGS)" \
LDFLAGS="$$(HOST_LDFLAGS)" \
$$($$(PKG)_CONF_ENV) \
CONFIG_SITE=/dev/null \
./configure \
--prefix="$$(HOST_DIR)" \
--sysconfdir="$$(HOST_DIR)/etc" \
--localstatedir="$$(HOST_DIR)/var" \
--enable-shared --disable-static \
--disable-gtk-doc \
--disable-gtk-doc-html \
--disable-doc \
--disable-docs \
--disable-documentation \
--disable-debug \
--with-xmlto=no \
--with-fop=no \
--disable-nls \
$$(if $$($$(PKG)_OVERRIDE_SRCDIR),,--disable-dependency-tracking) \
$$(QUIET) $$($$(PKG)_CONF_OPTS) \
)
endef
endif
endif
$(2)_POST_PATCH_HOOKS += UPDATE_CONFIG_HOOK
ifeq ($$($(2)_AUTORECONF),YES)
# This has to come before autoreconf
ifeq ($$($(2)_GETTEXTIZE),YES)
$(2)_PRE_CONFIGURE_HOOKS += GETTEXTIZE_HOOK
$(2)_DEPENDENCIES += host-gettext
endif
$(2)_PRE_CONFIGURE_HOOKS += AUTORECONF_HOOK
# default values are not evaluated yet, so don't rely on this defaulting to YES
ifneq ($$($(2)_LIBTOOL_PATCH),NO)
$(2)_PRE_CONFIGURE_HOOKS += LIBTOOL_PATCH_HOOK
endif
$(2)_DEPENDENCIES += host-automake host-autoconf host-libtool
else # ! AUTORECONF = YES
# default values are not evaluated yet, so don't rely on this defaulting to YES
ifneq ($$($(2)_LIBTOOL_PATCH),NO)
$(2)_POST_PATCH_HOOKS += LIBTOOL_PATCH_HOOK
endif
endif
# Append a configure hook if building for a powerpc64 (or powerpc64le) arch.
# Must be added after other pre-configure hooks that might regenerate the
# configure script and overwrite the changes made here.
ifneq ($$(filter powerpc64%,$$(if $$(filter target,$(4)),$$(ARCH),$$(HOSTARCH))),)
$(2)_PRE_CONFIGURE_HOOKS += CONFIGURE_FIX_POWERPC64_HOOK
endif
#
# Build step. Only define it if not already defined by the package .mk
# file.
#
ifndef $(2)_BUILD_CMDS
ifeq ($(4),target)
define $(2)_BUILD_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPTS) -C $$($$(PKG)_SRCDIR)
endef
else
define $(2)_BUILD_CMDS
$$(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_MAKE_OPTS) -C $$($$(PKG)_SRCDIR)
endef
endif
endif
#
# Host installation step. Only define it if not already defined by the
# package .mk file.
#
ifndef $(2)_INSTALL_CMDS
define $(2)_INSTALL_CMDS
$$(HOST_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_INSTALL_OPTS) -C $$($$(PKG)_SRCDIR)
endef
endif
#
# Staging installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_STAGING_CMDS
define $(2)_INSTALL_STAGING_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_INSTALL_STAGING_OPTS) -C $$($$(PKG)_SRCDIR)
endef
endif
#
# Target installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_TARGET_CMDS
define $(2)_INSTALL_TARGET_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE) $$($$(PKG)_INSTALL_TARGET_OPTS) -C $$($$(PKG)_SRCDIR)
endef
endif
# Call the generic package infrastructure to generate the necessary
# make targets
$(call inner-generic-package,$(1),$(2),$(3),$(4))
endef
################################################################################
# autotools-package -- the target generator macro for autotools packages
################################################################################
autotools-package = $(call inner-autotools-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
host-autotools-package = $(call inner-autotools-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)