Skip to contentSkip to conversation

generic packages: rename FOO_MAKE_OPTS into FOO_MAKE_OPT

PATCH New Thomas De Schampheleire 3 participants 10 messages Jul 22, 2014 – Jul 29, 2014 Arm/Allwinner sunXi SoC support

lore
Share & tools
lore

Thomas De Schampheleire

author
#0 lore raw

PATCH 1/1 generic packages: rename FOO_MAKE_OPTS into FOO_MAKE_OPT

The autotools infrastructure allows packages to specify FOO_MAKE_OPT and FOO_MAKE_ENV. The generic infrastructure does not use this variable, but some individual packages define them for use in their own BAR_CMDS.

However, some of these packages call this define FOO_MAKE_OPTS, rather than FOO_MAKE_OPT. This is currently not a real problem, but it is inconsistent. Moreover, the upcoming kconfig-package infrastructure will also use FOO_MAKE_OPT, so generic packages that also use kconfig-package have no choice but use the singular name.

Signed-off-by Thomas De Schampheleire <[email protected]>
---
 boot/uboot/uboot.mk                  |   6 +++---
 package/aircrack-ng/aircrack-ng.mk   |  10 +++++-----
 package/busybox/busybox.mk           |   8 ++++----
 package/dvb-apps/dvb-apps.mk         |   8 ++++----
 package/fmc/fmc.mk                   |   4 ++--
 package/fmlib/fmlib.mk               |   6 +++---
 package/gptfdisk/gptfdisk.mk         |   4 ++--
 package/linux-fusion/linux-fusion.mk |  20 ++++++++++----------
 package/pciutils/pciutils.mk         |   8 ++++----
 package/sunxi-mali/sunxi-mali.mk     |  20 ++++++++++----------
 package/ti-gfx/ti-gfx.mk             |  10 +++++-----
 package/trace-cmd/trace-cmd.mk       |   8 ++++----
 12 files changed, 56 insertions(+), 56 deletions(-)
boot/uboot/uboot.mk +3 -3
diff -r e79d6f3e1d9c -r 9d1a7e2626ad boot/uboot/uboot.mk
@@ -59,7 +59,7 @@
 UBOOT_ARCH=$(KERNEL_ARCH)
 
 UBOOT_CONFIGURE_OPTS += CONFIG_NOSOFTFLOAT=1
-UBOOT_MAKE_OPTS += \
+UBOOT_MAKE_OPT += \
 	CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
 	ARCH=$(UBOOT_ARCH)
 

@@ -96,7 +96,7 @@
 
 define UBOOT_CONFIGURE_CMDS
 	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) 	\
-		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS)		\
+		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPT)		\
 		$(UBOOT_BOARD_NAME)_config
 	@echo >> $(@D)/include/config.h
 	@echo "/* Add a wrapper around the values Buildroot sets. */" >> $(@D)/include/config.h

@@ -115,7 +115,7 @@
 
 define UBOOT_BUILD_CMDS
 	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) 	\
-		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPTS) 		\
+		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPT) 		\
 		$(UBOOT_MAKE_TARGET)
 endef
package/aircrack-ng/aircrack-ng.mk +5 -5
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/aircrack-ng/aircrack-ng.mk
@@ -11,13 +11,13 @@
 AIRCRACK_NG_DEPENDENCIES = openssl
 
 ifeq ($(BR2_PACKAGE_SQLITE),y)
-	AIRCRACK_NG_MAKE_OPTS = sqlite=true
-	AIRCRACK_NG_MAKE_OPTS += \
+	AIRCRACK_NG_MAKE_OPT = sqlite=true
+	AIRCRACK_NG_MAKE_OPT += \
 		LIBSQL="-lsqlite3$(if $(BR2_PREFER_STATIC_LIB), -ldl -lpthread)"
 
 	AIRCRACK_NG_DEPENDENCIES += sqlite
 else
-	AIRCRACK_NG_MAKE_OPTS = sqlite=false
+	AIRCRACK_NG_MAKE_OPT = sqlite=false
 endif
 
 AIRCRACK_NG_LDFLAGS = $(TARGET_LDFLAGS) -lz \

@@ -26,12 +26,12 @@
 define AIRCRACK_NG_BUILD_CMDS
 	$(TARGET_CONFIGURE_OPTS) $(MAKE1) CC="$(TARGET_CC)" LD="$(TARGET_LD)" \
 		LDFLAGS="$(AIRCRACK_NG_LDFLAGS)" \
-		-C $(@D) $(AIRCRACK_NG_MAKE_OPTS) all
+		-C $(@D) $(AIRCRACK_NG_MAKE_OPT) all
 endef
 
 define AIRCRACK_NG_INSTALL_TARGET_CMDS
 	$(TARGET_CONFIGURE_OPTS) $(MAKE1) -C $(@D) DESTDIR=$(TARGET_DIR) \
-		prefix=/usr $(AIRCRACK_NG_MAKE_OPTS) install
+		prefix=/usr $(AIRCRACK_NG_MAKE_OPT) install
 endef
 
 $(eval $(generic-package))
package/busybox/busybox.mk +4 -4
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/busybox/busybox.mk
@@ -32,7 +32,7 @@
 	$(TARGET_MAKE_ENV) \
 	CFLAGS="$(BUSYBOX_CFLAGS)" \
 	CFLAGS_busybox="$(BUSYBOX_CFLAGS_busybox)"
-BUSYBOX_MAKE_OPTS = \
+BUSYBOX_MAKE_OPT = \
 	CC="$(TARGET_CC)" \
 	ARCH=$(KERNEL_ARCH) \
 	PREFIX="$(TARGET_DIR)" \

@@ -209,11 +209,11 @@
 endef
 
 define BUSYBOX_BUILD_CMDS
-	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D)
+	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPT) -C $(@D)
 endef
 
 define BUSYBOX_INSTALL_TARGET_CMDS
-	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D) install
+	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPT) -C $(@D) install
 	if [ ! -f $(TARGET_DIR)/usr/share/udhcpc/default.script ]; then \
 		$(INSTALL) -m 0755 -D package/busybox/udhcpc.script \
 			$(TARGET_DIR)/usr/share/udhcpc/default.script; \

@@ -227,7 +227,7 @@
 $(eval $(generic-package))
 
 busybox-menuconfig busybox-xconfig busybox-gconfig: busybox-patch
-	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(BUSYBOX_DIR) \
+	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPT) -C $(BUSYBOX_DIR) \
 		$(subst busybox-,,$@)
 	rm -f $(BUSYBOX_DIR)/.stamp_built
 	rm -f $(BUSYBOX_DIR)/.stamp_target_installed
package/dvb-apps/dvb-apps.mk +4 -4
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/dvb-apps/dvb-apps.mk
@@ -16,7 +16,7 @@
 endif
 
 ifeq ($(BR2_PREFER_STATIC_LIB),y)
-DVB_APPS_MAKE_OPTS += static=1
+DVB_APPS_MAKE_OPT += static=1
 endif
 
 DVB_APPS_INSTALL_STAGING = YES

@@ -24,15 +24,15 @@
 define DVB_APPS_BUILD_CMDS
 	$(TARGET_CONFIGURE_OPTS) LDLIBS="$(DVB_APPS_LDLIBS)" \
 		$(MAKE) -C $(@D) CROSS_ROOT=$(STAGING_DIR) \
-		$(DVB_APPS_MAKE_OPTS)
+		$(DVB_APPS_MAKE_OPT)
 endef
 
 define DVB_APPS_INSTALL_STAGING_CMDS
-	$(MAKE) -C $(@D) $(DVB_APPS_MAKE_OPTS) DESTDIR=$(STAGING_DIR) install
+	$(MAKE) -C $(@D) $(DVB_APPS_MAKE_OPT) DESTDIR=$(STAGING_DIR) install
 endef
 
 define DVB_APPS_INSTALL_TARGET_CMDS
-	$(MAKE) -C $(@D) $(DVB_APPS_MAKE_OPTS) DESTDIR=$(TARGET_DIR) install
+	$(MAKE) -C $(@D) $(DVB_APPS_MAKE_OPT) DESTDIR=$(TARGET_DIR) install
 endef
 
 $(eval $(generic-package))
package/fmc/fmc.mk +2 -2
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/fmc/fmc.mk
@@ -10,7 +10,7 @@
 FMC_LICENSE_FILES = COPYING
 FMC_DEPENDENCIES = libxml2 tclap fmlib
 
-FMC_MAKE_OPTS = \
+FMC_MAKE_OPT = \
 	CC="$(TARGET_CC)" \
 	CXX="$(TARGET_CXX)" \
 	FMD_USPACE_HEADER_PATH="$(STAGING_DIR)/usr/include/fmd" \

@@ -20,7 +20,7 @@
 
 define FMC_BUILD_CMDS
 	# The linking step has dependency issues so using MAKE1
-	$(TARGET_MAKE_ENV) $(MAKE1) $(FMC_MAKE_OPTS) -C $(@D)/source
+	$(TARGET_MAKE_ENV) $(MAKE1) $(FMC_MAKE_OPT) -C $(@D)/source
 endef
 
 define FMC_INSTALL_TARGET_CMDS
package/fmlib/fmlib.mk +3 -3
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/fmlib/fmlib.mk
@@ -15,7 +15,7 @@
 # nothing to install to the target
 FMLIB_INSTALL_TARGET = NO
 
-FMLIB_MAKE_OPTS = \
+FMLIB_MAKE_OPT = \
 	CC="$(TARGET_CC)" \
 	CROSS_COMPILE="$(TARGET_CROSS)" \
 	KERNEL_SRC="$(LINUX_DIR)" \

@@ -26,11 +26,11 @@
 endif
 
 define FMLIB_BUILD_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE) $(FMLIB_MAKE_OPTS) -C $(@D) libfm-$(FMLIB_ARCHTYPE).a
+	$(TARGET_MAKE_ENV) $(MAKE) $(FMLIB_MAKE_OPT) -C $(@D) libfm-$(FMLIB_ARCHTYPE).a
 endef
 
 define FMLIB_INSTALL_STAGING_CMDS
-	$(FMLIB_MAKE_ENV) $(MAKE) $(FMLIB_MAKE_OPTS) -C $(@D) install-libfm-$(FMLIB_ARCHTYPE)
+	$(FMLIB_MAKE_ENV) $(MAKE) $(FMLIB_MAKE_OPT) -C $(@D) install-libfm-$(FMLIB_ARCHTYPE)
 endef
 
 $(eval $(generic-package))
package/gptfdisk/gptfdisk.mk +2 -2
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/gptfdisk/gptfdisk.mk
@@ -23,12 +23,12 @@
 
 ifeq ($(BR2_PACKAGE_ICU),y)
     GPTFDISK_DEPENDENCIES += icu
-    GPTFDISK_MAKE_OPTS += USE_UTF16=y
+    GPTFDISK_MAKE_OPT += USE_UTF16=y
 endif
 
 define GPTFDISK_BUILD_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) \
-		$(GPTFDISK_MAKE_OPTS) $(GPTFDISK_TARGETS_y)
+		$(GPTFDISK_MAKE_OPT) $(GPTFDISK_TARGETS_y)
 endef
 
 define GPTFDISK_INSTALL_TARGET_CMDS
package/linux-fusion/linux-fusion.mk +10 -10
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/linux-fusion/linux-fusion.mk
@@ -14,26 +14,26 @@
 LINUX_FOR_FUSION=$(LINUX_VERSION_PROBED)
 LINUX_FUSION_ETC_DIR=$(TARGET_DIR)/etc/udev/rules.d
 
-LINUX_FUSION_MAKE_OPTS =  KERNEL_VERSION=$(LINUX_FOR_FUSION)
-LINUX_FUSION_MAKE_OPTS += KERNEL_BUILD=$(LINUX_DIR)
-LINUX_FUSION_MAKE_OPTS += KERNEL_SOURCE=$(LINUX_DIR)
+LINUX_FUSION_MAKE_OPT =  KERNEL_VERSION=$(LINUX_FOR_FUSION)
+LINUX_FUSION_MAKE_OPT += KERNEL_BUILD=$(LINUX_DIR)
+LINUX_FUSION_MAKE_OPT += KERNEL_SOURCE=$(LINUX_DIR)
 
-LINUX_FUSION_MAKE_OPTS += SYSROOT=$(TARGET_DIR)
-LINUX_FUSION_MAKE_OPTS += ARCH=$(KERNEL_ARCH)
-LINUX_FUSION_MAKE_OPTS += CROSS_COMPILE=$(TARGET_CROSS)
-LINUX_FUSION_MAKE_OPTS += KERNEL_MODLIB=/lib/modules/$(LINUX_FOR_FUSION)/kernel
+LINUX_FUSION_MAKE_OPT += SYSROOT=$(TARGET_DIR)
+LINUX_FUSION_MAKE_OPT += ARCH=$(KERNEL_ARCH)
+LINUX_FUSION_MAKE_OPT += CROSS_COMPILE=$(TARGET_CROSS)
+LINUX_FUSION_MAKE_OPT += KERNEL_MODLIB=/lib/modules/$(LINUX_FOR_FUSION)/kernel
 
 define LINUX_FUSION_BUILD_CMDS
-	$(TARGET_CONFIGURE_OPTS) $(MAKE) $(LINUX_FUSION_MAKE_OPTS) -C $(@D)
+	$(TARGET_CONFIGURE_OPTS) $(MAKE) $(LINUX_FUSION_MAKE_OPT) -C $(@D)
 endef
 
 define LINUX_FUSION_INSTALL_STAGING_CMDS
-	$(TARGET_CONFIGURE_OPTS) $(MAKE) $(LINUX_FUSION_MAKE_OPTS) INSTALL_MOD_PATH=$(STAGING_DIR) -C $(@D) headers_install
+	$(TARGET_CONFIGURE_OPTS) $(MAKE) $(LINUX_FUSION_MAKE_OPT) INSTALL_MOD_PATH=$(STAGING_DIR) -C $(@D) headers_install
 endef
 
 define LINUX_FUSION_INSTALL_TARGET_CMDS
 	$(TARGET_CONFIGURE_OPTS) $(MAKE) \
-		$(LINUX_FUSION_MAKE_OPTS) \
+		$(LINUX_FUSION_MAKE_OPT) \
 		INSTALL_MOD_PATH=$(TARGET_DIR) \
 		-C $(@D) install
 	mkdir -p $(LINUX_FUSION_ETC_DIR)
package/pciutils/pciutils.mk +4 -4
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/pciutils/pciutils.mk
@@ -32,7 +32,7 @@
 	PCIUTILS_SHARED=yes
 endif
 
-PCIUTILS_MAKE_OPTS = \
+PCIUTILS_MAKE_OPT = \
 	CC="$(TARGET_CC)" \
 	HOST="$(KERNEL_ARCH)-linux" \
 	OPT="$(TARGET_CFLAGS)" \

@@ -58,17 +58,17 @@
 endef
 
 define PCIUTILS_BUILD_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) $(PCIUTILS_MAKE_OPTS) \
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) $(PCIUTILS_MAKE_OPT) \
 		PREFIX=/usr
 endef
 
 define PCIUTILS_INSTALL_TARGET_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) $(PCIUTILS_MAKE_OPTS) \
+	$(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) $(PCIUTILS_MAKE_OPT) \
 		PREFIX=$(TARGET_DIR)/usr install install-lib install-pcilib
 endef
 
 define PCIUTILS_INSTALL_STAGING_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) $(PCIUTILS_MAKE_OPTS) \
+	$(TARGET_MAKE_ENV) $(MAKE1) -C $(@D) $(PCIUTILS_MAKE_OPT) \
 		PREFIX=$(STAGING_DIR)/usr install install-lib install-pcilib
 endef
package/sunxi-mali/sunxi-mali.mk +10 -10
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/sunxi-mali/sunxi-mali.mk
@@ -24,21 +24,21 @@
 	$(TARGET_MAKE_ENV)
 
 ifeq ($(BR2_ARM_EABIHF),y)
-SUNXI_MALI_MAKE_OPTS += ABI=armhf
+SUNXI_MALI_MAKE_OPT += ABI=armhf
 else
-SUNXI_MALI_MAKE_OPTS += ABI=armel
+SUNXI_MALI_MAKE_OPT += ABI=armel
 endif
 
-SUNXI_MALI_MAKE_OPTS += EGL_TYPE=framebuffer
+SUNXI_MALI_MAKE_OPT += EGL_TYPE=framebuffer
 
 ifeq ($(BR2_PACKAGE_SUNXI_MALI_R2P4),y)
-SUNXI_MALI_MAKE_OPTS += VERSION=r2p4
+SUNXI_MALI_MAKE_OPT += VERSION=r2p4
 endif
 ifeq ($(BR2_PACKAGE_SUNXI_MALI_R3P0),y)
-SUNXI_MALI_MAKE_OPTS += VERSION=r3p0
+SUNXI_MALI_MAKE_OPT += VERSION=r3p0
 endif
 ifeq ($(BR2_PACKAGE_SUNXI_MALI_R3P1),y)
-SUNXI_MALI_MAKE_OPTS += VERSION=r3p1
+SUNXI_MALI_MAKE_OPT += VERSION=r3p1
 endif
 
 define SUNXI_MALI_GIT_SUBMODULE_FIXUP

@@ -49,17 +49,17 @@
 SUNXI_MALI_PRE_CONFIGURE_HOOKS += SUNXI_MALI_GIT_SUBMODULE_FIXUP
 
 define SUNXI_MALI_BUILD_CMDS
-	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D) $(SUNXI_MALI_MAKE_OPTS) all
+	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D) $(SUNXI_MALI_MAKE_OPT) all
 	$(TARGET_CC) $(TARGET_CFLAGS) -o $(@D)/version/version \
 		$(@D)/version/version.c
 endef
 
 define SUNXI_MALI_INSTALL_STAGING_CMDS
 	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D) \
-		$(SUNXI_MALI_MAKE_OPTS) DESTDIR=$(STAGING_DIR) install
+		$(SUNXI_MALI_MAKE_OPT) DESTDIR=$(STAGING_DIR) install
 	# test must be built after install because it depends on headers that are
 	# generated during the install above.
-	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D) $(SUNXI_MALI_MAKE_OPTS) test
+	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D) $(SUNXI_MALI_MAKE_OPT) test
 	$(INSTALL) -D -m 0644 package/sunxi-mali/egl.pc \
 		$(STAGING_DIR)/usr/lib/pkgconfig/egl.pc
 	$(INSTALL) -D -m 0644 package/sunxi-mali/glesv2.pc \

@@ -68,7 +68,7 @@
 
 define SUNXI_MALI_INSTALL_TARGET_CMDS
 	$(SUNXI_MALI_MAKE_ENV) $(MAKE) -C $(@D)/lib \
-		$(SUNXI_MALI_MAKE_OPTS) DESTDIR=$(TARGET_DIR) install
+		$(SUNXI_MALI_MAKE_OPT) DESTDIR=$(TARGET_DIR) install
 	$(if $(BR2_PACKAGE_SUNXI_MALI_DBG),
 		$(INSTALL) -m 755 $(@D)/version/version $(TARGET_DIR)/usr/bin/maliver; \
 		$(INSTALL) -m 755 $(@D)/test/test $(TARGET_DIR)/usr/bin/malitest
package/ti-gfx/ti-gfx.mk +5 -5
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/ti-gfx/ti-gfx.mk
@@ -50,7 +50,7 @@
 
 TI_GFX_BIN_PATH = gfx_$(TI_GFX_DEBUG_LIB)_es$(TI_GFX_OMAPES)
 
-TI_GFX_KM_MAKE_OPTS = \
+TI_GFX_KM_MAKE_OPT = \
 	$(LINUX_MAKE_FLAGS) \
 	BUILD=$(TI_GFX_DEBUG_KM) \
 	TI_PLATFORM=$(TI_GFX_PLATFORM) \

@@ -58,7 +58,7 @@
 	SUPPORT_XORG=0 \
 	KERNELDIR=$(LINUX_DIR)
 
-TI_GFX_DEMO_MAKE_OPTS = \
+TI_GFX_DEMO_MAKE_OPT = \
 	PLATFORM=LinuxARMV7 \
 	X11BUILD=0 \
 	PLAT_CC="$(TARGET_CC)" \

@@ -100,7 +100,7 @@
 endef
 
 define TI_GFX_BUILD_KM_CMDS
-	$(MAKE) $(TI_GFX_KM_MAKE_OPTS) -C $(@D)/GFX_Linux_KM all
+	$(MAKE) $(TI_GFX_KM_MAKE_OPT) -C $(@D)/GFX_Linux_KM all
 endef
 
 ifeq ($(BR2_PACKAGE_TI_GFX_DEMOS),y)

@@ -108,7 +108,7 @@
 	$(foreach demo, $(TI_GFX_DEMOS), \
 		$(TARGET_MAKE_ENV) $(MAKE1) -C \
 			$(@D)/$(TI_GFX_DEMOS_LOC)/$(demo)/$(TI_GFX_DEMOS_MAKE_LOC) \
-			$(TI_GFX_DEMO_MAKE_OPTS) all
+			$(TI_GFX_DEMO_MAKE_OPT) all
 	)
 endef
 endif

@@ -155,7 +155,7 @@
 endef
 
 define TI_GFX_INSTALL_KM_CMDS
-	$(MAKE) $(TI_GFX_KM_MAKE_OPTS) -C $(@D)/GFX_Linux_KM install
+	$(MAKE) $(TI_GFX_KM_MAKE_OPT) -C $(@D)/GFX_Linux_KM install
 endef
 
 define TI_GFX_INSTALL_BINS_CMDS
package/trace-cmd/trace-cmd.mk +4 -4
diff -r e79d6f3e1d9c -r 9d1a7e2626ad package/trace-cmd/trace-cmd.mk
@@ -15,12 +15,12 @@
 
 ifeq ($(BR2_PACKAGE_PYTHON),y)
 TRACE_CMD_DEPENDENCIES += python host-swig
-TRACE_CMD_MAKE_OPTS = PYTHON_VERS=python
+TRACE_CMD_MAKE_OPT = PYTHON_VERS=python
 else ifeq ($(BR2_PACKAGE_PYTHON3),y)
 TRACE_CMD_DEPENDENCIES += python3 host-swig
-TRACE_CMD_MAKE_OPTS = PYTHON_VERS=python3
+TRACE_CMD_MAKE_OPT = PYTHON_VERS=python3
 else
-TRACE_CMD_MAKE_OPTS += NO_PYTHON=1
+TRACE_CMD_MAKE_OPT += NO_PYTHON=1
 endif
 
 # trace-cmd already defines _LARGEFILE64_SOURCE when necessary,

@@ -36,7 +36,7 @@
 	$(MAKE) $(TARGET_CONFIGURE_OPTS) \
 		CFLAGS="$(TRACE_CMD_CFLAGS)" \
 		CPPFLAGS="$(TRACE_CMD_CPPFLAGS)" \
-		$(TRACE_CMD_MAKE_OPTS) \
+		$(TRACE_CMD_MAKE_OPT) \
 		-C $(@D) all
 endef
author
#1 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

As FOO_MAKE_OPTS has been renamed to FOO_MAKE_OPT, this patch renames FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT for symmetry reasons.

Signed-off-by Thomas De Schampheleire <[email protected]>

---
Note: TARGET_CONFIGURE_OPTS has not been changed since the impact is very large. It would make sense to change it too, though, so let me know what you think.

 boot/uboot/uboot.mk                  |    6 +-
 package/fbv/fbv.mk                   |   10 +-
 package/qt/qt.mk                     |  214 +++++++++++++++---------------
 package/qt5/qt5base/qt5base.mk       |   72 +++++-----
 package/sunxi-cedarx/sunxi-cedarx.mk |    4 +-
 5 files changed, 153 insertions(+), 153 deletions(-)
boot/uboot/uboot.mk +3 -3
diff -r 9d1a7e2626ad -r 5b961fc80eb2 boot/uboot/uboot.mk
@@ -58,7 +58,7 @@
 
 UBOOT_ARCH=$(KERNEL_ARCH)
 
-UBOOT_CONFIGURE_OPTS += CONFIG_NOSOFTFLOAT=1
+UBOOT_CONFIGURE_OPT += CONFIG_NOSOFTFLOAT=1
 UBOOT_MAKE_OPT += \
 	CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
 	ARCH=$(UBOOT_ARCH)

@@ -95,7 +95,7 @@
 endif
 
 define UBOOT_CONFIGURE_CMDS
-	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) 	\
+	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPT) 	\
 		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPT)		\
 		$(UBOOT_BOARD_NAME)_config
 	@echo >> $(@D)/include/config.h

@@ -114,7 +114,7 @@
 endef
 
 define UBOOT_BUILD_CMDS
-	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPTS) 	\
+	$(TARGET_CONFIGURE_OPTS) $(UBOOT_CONFIGURE_OPT) 	\
 		$(MAKE) -C $(@D) $(UBOOT_MAKE_OPT) 		\
 		$(UBOOT_MAKE_TARGET)
 endef
package/fbv/fbv.mk +5 -5
diff -r 9d1a7e2626ad -r 5b961fc80eb2 package/fbv/fbv.mk
@@ -12,21 +12,21 @@
 
 ### image format dependencies and configure options
 FBV_DEPENDENCIES = # empty
-FBV_CONFIGURE_OPTS = # empty
+FBV_CONFIGURE_OPT = # empty
 ifeq ($(BR2_PACKAGE_FBV_PNG),y)
 FBV_DEPENDENCIES += libpng
 else
-FBV_CONFIGURE_OPTS += --without-libpng
+FBV_CONFIGURE_OPT += --without-libpng
 endif
 ifeq ($(BR2_PACKAGE_FBV_JPEG),y)
 FBV_DEPENDENCIES += jpeg
 else
-FBV_CONFIGURE_OPTS += --without-libjpeg
+FBV_CONFIGURE_OPT += --without-libjpeg
 endif
 ifeq ($(BR2_PACKAGE_FBV_GIF),y)
 FBV_DEPENDENCIES += libungif
 else
-FBV_CONFIGURE_OPTS += --without-libungif
+FBV_CONFIGURE_OPT += --without-libungif
 endif
 
 #fbv donesn't support cross-compilation

@@ -36,7 +36,7 @@
 		$(TARGET_CONFIGURE_ARGS) \
 		./configure \
 		--prefix=/usr \
-		$(FBV_CONFIGURE_OPTS) \
+		$(FBV_CONFIGURE_OPT) \
 	)
 endef
package/qt/qt.mk +107 -107

486 lines not on this page · raw message

package/qt5/qt5base/qt5base.mk +36 -36

162 lines not on this page · raw message

package/sunxi-cedarx/sunxi-cedarx.mk +2 -2
diff -r 9d1a7e2626ad -r 5b961fc80eb2 package/sunxi-cedarx/sunxi-cedarx.mk
@@ -9,7 +9,7 @@
 
 SUNXI_CEDARX_INSTALL_STAGING = YES
 
-SUNXI_CEDARX_CONFIGURE_OPTS = \
+SUNXI_CEDARX_CONFIGURE_OPT = \
 	CROSS_COMPILE=$(TARGET_CROSS)
 
 ifeq ($(BR2_ARM_EABIHF),y)

@@ -35,7 +35,7 @@
 
 define SUNXI_CEDARX_BUILD_CMDS
 	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(SUNXI_CEDARX_BIN_DIR) \
-		$(SUNXI_CEDARX_CONFIGURE_OPTS)
+		$(SUNXI_CEDARX_CONFIGURE_OPT)
 	$(SUNXI_CEDARX_BUILD_AVHEAP)
 endef
#2 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

Dear Thomas De Schampheleire,

Quoted 9 lines · Thomas De Schampheleire

As FOO_MAKE_OPTS has been renamed to FOO_MAKE_OPT, this patch renames FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT for symmetry reasons.

Signed-off-by Thomas De Schampheleire <[email protected]>

---
Note: TARGET_CONFIGURE_OPTS has not been changed since the impact is very large. It would make sense to change it too, though, so let me know what you think.

Yeah, I'm a bit worried with the discrepancy between TARGET_CONFIGURE_OPTS, TARGET_CONFIGURE_ARGS, HOST_CONFIGURE_OPTS and HOST_CONFIGURE_ARGS that use the plural form, vs those per-package <foobar>_OPT options.

My feeling is that the plural form looks more logical, so instead of moving from _OPTS to _OPT, I'd rather like to see a move from _OPT to _OPTS. But that indeed involves changing a *lot* of packages.

What do others think?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#3 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

Thomas Petazzoni <[email protected]> schreef:

Quoted 13 lines

Dear Thomas De Schampheleire,

Quoted 9 lines · Thomas De Schampheleire

As FOO_MAKE_OPTS has been renamed to FOO_MAKE_OPT, this patch renames FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT for symmetry reasons.

Signed-off-by Thomas De Schampheleire <[email protected]>

---
Note: TARGET_CONFIGURE_OPTS has not been changed since the impact is very large. It would make sense to change it too, though, so let me know what you think.

Quoted 8 lines

Yeah, I'm a bit worried with the discrepancy between TARGET_CONFIGURE_OPTS, TARGET_CONFIGURE_ARGS, HOST_CONFIGURE_OPTS and HOST_CONFIGURE_ARGS that use the plural form, vs those per-package <foobar>_OPT options.

My feeling is that the plural form looks more logical, so instead of moving from _OPTS to _OPT, I'd rather like to see a move from _OPT to _OPTS. But that indeed involves changing a *lot* of packages.

For me, the amount of touched packages is not important. We have done mass changes in the past, even for simple cleanup.

The question is: do we need to care about BR2_EXTERNAL users? Yann objected
against this type of change with that argument.
My opinion is: no, we never declared that the infra is stable, so when updating to a newer Buildroot release may involve some changes to your external packages, just as
was the case before BR2_EXTERNAL existed, for non-submitted packages of a company/project.

We could add a simple check to warn users of _OPT, but not more than that.

Best regards,
Thomas

#4 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

Thomas?, All,

On 2014-07-27 16:33 +0200, Thomas De Schampheleire spake thusly:

Quoted 19 lines

Thomas Petazzoni <[email protected]> schreef:

Quoted 18 lines

Dear Thomas De Schampheleire,

Quoted 9 lines · Thomas De Schampheleire

As FOO_MAKE_OPTS has been renamed to FOO_MAKE_OPT, this patch renames FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT for symmetry reasons.

Signed-off-by Thomas De Schampheleire <[email protected]>

---
Note: TARGET_CONFIGURE_OPTS has not been changed since the impact is very large. It would make sense to change it too, though, so let me know what you think.

Yeah, I'm a bit worried with the discrepancy between TARGET_CONFIGURE_OPTS, TARGET_CONFIGURE_ARGS, HOST_CONFIGURE_OPTS and HOST_CONFIGURE_ARGS that use the plural form, vs those per-package <foobar>_OPT options.

Quoted 6 lines
Quoted 3 lines

My feeling is that the plural form looks more logical, so instead of moving from _OPTS to _OPT, I'd rather like to see a move from _OPT to _OPTS. But that indeed involves changing a *lot* of packages.

For me, the amount of touched packages is not important. We have done mass changes in the past, even for simple cleanup.

Indeed. It means the review is a bit more involved, but OK.

Quoted 8 lines

The question is: do we need to care about BR2_EXTERNAL users? Yann objected
against this type of change with that argument.
My opinion is: no, we never declared that the infra is stable, so when updating to a newer Buildroot release may involve some changes to your external packages, just as
was the case before BR2_EXTERNAL existed, for non-submitted packages of a company/project.

We could add a simple check to warn users of _OPT, but not more than that.

OK, I'm siding with you guys. OK for the renaming.

But then we should add a check that the old variable gets used, and _error out_ in such case. If we just warn, the warning will be lost amongst all the other messages, nad will bbe missed; and suddenly, br2-external packages fails to build, or build in an unexpected configuration.

I agree with you that we should just check if the old variable is set, but we should not try to correct the situation.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#5 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

Dear Yann E. MORIN,

Quoted 4 lines · Yann E. MORIN
Quoted 1 line

We could add a simple check to warn users of _OPT, but not more than that.

OK, I'm siding with you guys. OK for the renaming.

Quoted 8 lines

But then we should add a check that the old variable gets used, and _error out_ in such case. If we just warn, the warning will be lost amongst all the other messages, nad will bbe missed; and suddenly, br2-external packages fails to build, or build in an unexpected configuration.

I agree with you that we should just check if the old variable is set, but we should not try to correct the situation.

I fully agree with this: we should error out if the old variable is used, so that things are clearly noticed by users.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#6 lore raw

PATCH 1/1 generic packages: rename FOO_CONFIGURE_OPTS into FOO_CONFIGURE_OPT

Quoted 14 lines · Thomas Petazzoni

Dear Yann E. MORIN,

Quoted 10 lines · Yann E. MORIN
Quoted 1 line

We could add a simple check to warn users of _OPT, but not more than that.

OK, I'm siding with you guys. OK for the renaming.

But then we should add a check that the old variable gets used, and _error out_ in such case. If we just warn, the warning will be lost amongst all the other messages, nad will bbe missed; and suddenly, br2-external packages fails to build, or build in an unexpected configuration.

Quoted 5 lines
Quoted 2 lines

I agree with you that we should just check if the old variable is set, but we should not try to correct the situation.

I fully agree with this: we should error out if the old variable is used, so that things are clearly noticed by users.

Ok, great.
I'm working on this...

author
#7 lore raw

PATCH 1/1 generic packages: rename FOO_MAKE_OPTS into FOO_MAKE_OPT

In reply to Thomas De Schampheleire

Thomas De Schampheleire <[email protected]> schreef:

Quoted 9 lines

The autotools infrastructure allows packages to specify FOO_MAKE_OPT and FOO_MAKE_ENV. The generic infrastructure does not use this variable, but some individual packages define them for use in their own BAR_CMDS.

However, some of these packages call this define FOO_MAKE_OPTS, rather than FOO_MAKE_OPT. This is currently not a real problem, but it is inconsistent. Moreover, the upcoming kconfig-package infrastructure will also use FOO_MAKE_OPT, so generic packages that also use kconfig-package have no choice but use the singular name.

This last reason isn't really valid as the kconfig infra could choose to use OPTS iso OPT.

Note that I personally find OPTS more logical, but I do think we should be consistent between autotools and generic.
We could also go in the other direction and change pkg-autotools and the depending packages to use OPTS. What do you think of that? Thinking twice about this patch, this last approach has my preference, it would also avoid the strange situation regarding TARGET_CONFIGURE_OPTS, see second patch.

Thanks,
Thomas

NAK
#8 lore raw

PATCH 1/1 generic packages: rename FOO_MAKE_OPTS into FOO_MAKE_OPT

Thomas, All,

On 2014-07-22 21:55 +0200, Thomas De Schampheleire spake thusly:

Quoted 11 lines

Thomas De Schampheleire <[email protected]> schreef:

Quoted 9 lines

The autotools infrastructure allows packages to specify FOO_MAKE_OPT and FOO_MAKE_ENV. The generic infrastructure does not use this variable, but some individual packages define them for use in their own BAR_CMDS.

However, some of these packages call this define FOO_MAKE_OPTS, rather than FOO_MAKE_OPT. This is currently not a real problem, but it is inconsistent. Moreover, the upcoming kconfig-package infrastructure will also use FOO_MAKE_OPT, so generic packages that also use kconfig-package have no choice but use the singular name.

Quoted 5 lines

This last reason isn't really valid as the kconfig infra could choose to use OPTS iso OPT.

Note that I personally find OPTS more logical, but I do think we should be consistent between autotools and generic.

Agreed.

Quoted 2 lines

We could also go in the other direction and change pkg-autotools and the depending packages to use OPTS. What do you think of that?

NAK, because of br2-external. If we were to s/OPT/OPTS/ then all existing br2-external packages would be broken.

We could somewhat limit this brokenness by accepting the legacy OPT, and warn the user that his packages are using the old variable. Since we would not be using the OPT variable for anything else, that would be somewhat workable, but we'd have an ugly kludge in our code.

But I find it a gratuituous change.

OK, we fsked up the API to begin with. Let's accept it, and move on! ;-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#9 lore raw

PATCH 1/1 generic packages: rename FOO_MAKE_OPTS into FOO_MAKE_OPT

"Yann E. MORIN" <[email protected]> schreef:

Quoted 20 lines

Thomas, All,

On 2014-07-22 21:55 +0200, Thomas De Schampheleire spake thusly:

Quoted 11 lines

Thomas De Schampheleire <[email protected]> schreef:

Quoted 9 lines

The autotools infrastructure allows packages to specify FOO_MAKE_OPT and FOO_MAKE_ENV. The generic infrastructure does not use this variable, but some individual packages define them for use in their own BAR_CMDS.

However, some of these packages call this define FOO_MAKE_OPTS, rather than FOO_MAKE_OPT. This is currently not a real problem, but it is inconsistent. Moreover, the upcoming kconfig-package infrastructure will also use FOO_MAKE_OPT, so generic packages that also use kconfig-package have no choice but use the singular name.

Quoted 5 lines

This last reason isn't really valid as the kconfig infra could choose to use OPTS iso OPT.

Note that I personally find OPTS more logical, but I do think we should be consistent between autotools and generic.

Quoted 7 lines

Agreed.

Quoted 2 lines

We could also go in the other direction and change pkg-autotools and the depending packages to use OPTS. What do you think of that?

NAK, because of br2-external. If we were to s/OPT/OPTS/ then all existing br2-external packages would be broken.

I think we should be careful in using this as argument, because it very soon means that we cannot change anything anymore in the infrastructure.

In the past, developers adding custom packages to Buildroot also had to deal with changes in the infra. Moving to external doesn't change that.

Quoted 9 lines

We could somewhat limit this brokenness by accepting the legacy OPT, and warn the user that his packages are using the old variable. Since we would not be using the OPT variable for anything else, that would be somewhat workable, but we'd have an ugly kludge in our code.

But I find it a gratuituous change.

OK, we fsked up the API to begin with. Let's accept it, and move on! ;-)

A real problem will occur when we add a package that is both using autotools and kconfig, That's my original intention with these patches, how do you think we should handle that?

Thanks,
Thomas