Skip to contentSkip to conversation

core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

RFC PATCH New Yann E. MORIN 3 participants 19 messages Dec 21, 2015 – Dec 22, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Hello All!

This RFC series is an attempt at solving once and for all the problem we encounter with foo-config scripts.

The foo-config scripts are usually installed in staging, so are out of the PATH. However, most packages will just simply want to run them, and most are not configurable in where to look for that script and just expect to find them in the PATH.

Up until now, we used to patch those packages so that they accept an environment variable.

Arnout has suggested [0] that we move all the target-related foo-config scripts early in the PATH, so that they are found before the host ones and before the system ones.

This would allow us to drop our local patches, and to no longer set the custom FOO_CONFIG or the ac_cv_foo_config variables from our package recipes.

This series is my proposal to implement Arnout's suggestion, and is articulated as thus:

- first, we ensure that we install the munged foo-config scripts in their own location (patches 1-3),

- then we separate again the host and target PATHs variables (patch 4)

- finally, we use the proper host or target PATH everywhere we set

    PATH (patches 5-7).

- a preliminary cleanup patch against libhid concludes the series

    (patch 8)

This series is RFC: it is a "technology-preview" for early comments and to see if the solution is viable.

The series makes it so that our currently workarounds still work. When/if the topic is accepted (and the series is fixed after the reviews), we can then (un)fix / (un)patch packages in follow-up patches.

[0] http://lists.busybox.net/pipermail/buildroot/2015-December/146959.html

Regards,
Yann E. MORIN.

The following changes since commit 0848e9e89c2c427ab6ca35fab25996d7a1cd8c5b:

luvi: new package (2015-12-20 23:13:02 +0100)

are available in the git repository at:

git://git.busybox.net/~ymorin/git/buildroot yem/foo-config-in-PATH

for you to fetch changes up to 5927b9370935b82aedcdcade5cdd5d9c280528d5:

package/libhid: no need for custom PATH (2015-12-21 12:34:06 +0100)

----------------------------------------------------------------
Yann E. MORIN (8):
core: split long line of directories
core/pkg-generic: use a $(foreach) loop to fix foo-config scripts core/pkg-generic: install foo-config scripts in their own dir
core: re-instate different target and host PATHs
fs: use HOST_PATH
packages: use HOST_PATH
packages: use TARGET_PATH
package/libhid: no need for custom PATH

 Makefile                     | 15 ++++++++++++---
 fs/common.mk                 |  6 +++---
 fs/ext2/ext2.mk              |  2 +-
 package/Makefile.in          | 10 +++++-----
 package/faifa/faifa.mk       |  2 +-
 package/freetype/freetype.mk |  2 +-
 package/gpm/gpm.mk           |  2 +-
 package/kodi/kodi.mk         |  2 +-
 package/libhid/libhid.mk     |  4 +---
 package/pkg-cmake.mk         |  4 ++--
 package/pkg-generic.mk       |  5 ++++-
 package/pkg-python.mk        |  8 ++++----
 package/sdl/sdl.mk           |  2 +-
 13 files changed, 37 insertions(+), 27 deletions(-)
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.  |
'------------------------------^-------^------------------^--------------------'
#1 lore raw

RFC PATCH 1/8 core: split long line of directories

More are coming, so split for readability.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
---
 Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Makefile +3 -1
index dc657d9..f2b09ad 100644
@@ -445,7 +445,9 @@ world: target-post-image
 # dependencies anywhere else
 #
 ################################################################################
-$(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
+$(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR):
+	@mkdir -p $@
+$(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
 	@mkdir -p $@
 
 # We make a symlink lib32->lib or lib64->lib as appropriate
Signature · 1 line
1.9.1
#2 lore raw

RFC PATCH 2/8 core/pkg-generic: use a $(foreach) loop to fix foo-config scripts

In reply to Yann E. MORIN

Currently, we fix all the foo-config scripts of a package in one sed invocation. We can do so because we fix them in-place.

However, we're in the process of moving the fixed foo-config scripts to their own directory, so we'll need to be able to sed them one by one.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
---
 package/pkg-generic.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
package/pkg-generic.mk +2 -1
index 1e024d3..69349f6 100644
@@ -238,6 +238,7 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 	$(foreach hook,$($(PKG)_POST_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
 	$(Q)if test -n "$($(PKG)_CONFIG_SCRIPTS)" ; then \
 		$(call MESSAGE,"Fixing package configuration files") ;\
+		$(foreach s,$($(PKG)_CONFIG_SCRIPTS),\
 			$(SED)  "s,$(BASE_DIR), at BASE_DIR@,g" \
 				-e "s,$(STAGING_DIR), at STAGING_DIR@,g" \
 				-e "s,^\(exec_\)\?prefix=.*,\1prefix=@STAGING_DIR@/usr,g" \
@@ -245,7 +246,7 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 				-e "s,-L/usr/,-L at STAGING_DIR@/usr/,g" \
 				-e "s, at STAGING_DIR@,$(STAGING_DIR),g" \
 				-e "s, at BASE_DIR@,$(BASE_DIR),g" \
-				$(addprefix $(STAGING_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ;\
+				$(STAGING_DIR)/usr/bin/$(s); ) \
 	fi
 	@$(call MESSAGE,"Fixing libtool files")
 	$(Q)find $(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
Signature · 1 line
1.9.1
#3 lore raw

RFC PATCH 3/8 core/pkg-generic: install foo-config scripts in their own dir

In reply to Yann E. MORIN

After we fixup the foo-config scripts of a package, copy them to their own directory that we put early in the PATH, so that packges that hard-code calls to foo-config will find them automatically and avoid finding those of the host.

Note that we do keep the fixed-up scripts in staging, because we already pass 'FOO_CONFIG=$(STAGING)/usr/bin/foo-config' to a lot of packages, some for which we even have patches to accept the FOO_CONFIG environment variables. We need to unpatch those packages before we can just move the fixed-up foo-config scripts out of staging.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
---
 Makefile               | 7 +++++--
 package/pkg-generic.mk | 4 +++-
 2 files changed, 8 insertions(+), 3 deletions(-)
Makefile +5 -2
index f2b09ad..780b596 100644
@@ -363,6 +363,9 @@ TAR_OPTIONS = $(call qstrip,$(BR2_TAR_OPTIONS)) -xf
 # packages compiled for the host go here
 HOST_DIR := $(call qstrip,$(BR2_HOST_DIR))
 
+# foo-config scripts for the target go here
+FOO_CONFIG_DIR := $(HOST_DIR)/opt/foo-config
+
 # Quotes are needed for spaces and all in the original PATH content.
 BR_PATH = "$(HOST_DIR)/bin:$(HOST_DIR)/sbin:$(HOST_DIR)/usr/bin:$(HOST_DIR)/usr/sbin:$(PATH)"
 
@@ -426,7 +429,7 @@ include fs/common.mk
 include $(BR2_EXTERNAL)/external.mk
 
 dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
-	$(HOST_DIR) $(BINARIES_DIR)
+	$(HOST_DIR) $(BINARIES_DIR) $(FOO_CONFIG_DIR)
 
 $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
 	$(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig
@@ -445,7 +448,7 @@ world: target-post-image
 # dependencies anywhere else
 #
 ################################################################################
-$(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR):
+$(BUILD_DIR) $(TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(FOO_CONFIG_DIR):
 	@mkdir -p $@
 $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
 	@mkdir -p $@
package/pkg-generic.mk +3 -1
index 69349f6..6e3aee1 100644
@@ -246,7 +246,9 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 				-e "s,-L/usr/,-L at STAGING_DIR@/usr/,g" \
 				-e "s, at STAGING_DIR@,$(STAGING_DIR),g" \
 				-e "s, at BASE_DIR@,$(BASE_DIR),g" \
-				$(STAGING_DIR)/usr/bin/$(s); ) \
+				$(STAGING_DIR)/usr/bin/$(s); \
+			$(INSTALL) -m 0755 -D $(STAGING_DIR)/usr/bin/$(s) \
+				$(FOO_CONFIG_DIR)/$(s); ) \
 	fi
 	@$(call MESSAGE,"Fixing libtool files")
 	$(Q)find $(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
Signature · 1 line
1.9.1
#4 lore raw

RFC PATCH 3/8 core/pkg-generic: install foo-config scripts in their own dir

Hi Yann,

Makefile TAR_OPTIONS = $(call qstrip,$(BR2_TAR_OPTIONS)) -xf · line 367

Quoted 2 lines · Yann E. MORIN
Makefile +2 -0
+# foo-config scripts for the target go here
+FOO_CONFIG_DIR := $(HOST_DIR)/opt/foo-config

That's an unusual name for "real" identifiers and directories. But maybe it's just me. How about LIB_CONFIG_SCRIPT_DIR instead?

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#5 lore raw

RFC PATCH 3/8 core/pkg-generic: install foo-config scripts in their own dir

Baruch, All,

On 2015-12-21 20:51 +0200, Baruch Siach spake thusly:

Quoted 6 lines · Yann E. MORIN

Makefile TAR_OPTIONS = $(call qstrip,$(BR2_TAR_OPTIONS)) -xf · line 367

Quoted 2 lines
Makefile +2 -0
+# foo-config scripts for the target go here
+FOO_CONFIG_DIR := $(HOST_DIR)/opt/foo-config

That's an unusual name for "real" identifiers and directories. But maybe it's just me. How about LIB_CONFIG_SCRIPT_DIR instead?

Oh, well, 'foo-config' just has stuck, and I tried to keep it short. Since it is used only in a very few locations, LIB_CONFIG_SCRIPT_DIR is pretty OK, so I don't minf renaming.

Thanks!

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.  |
'------------------------------^-------^------------------^--------------------'
#6 lore raw

RFC PATCH 4/8 core: re-instate different target and host PATHs

In reply to Yann E. MORIN

In b989976 and previous commits, the differentiation between host and target PATH has been removed, because there was no reason at that time to have two different PATHs.

We now have the foo-config scripts installed in their own directory, and that has to come first in the PATH when building for the target. However, we do not want to use those directories for the host packages, as those foo-config scripts are only for the target packages.

So, we need to differentiate the host and target PATHs again.

This is a preparatory commit, which only introduces the two new variables. Follow-up patches will make use of those variables in the proper locations.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
Cc Samuel Martin <[email protected]>
---
 Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
Makefile +5 -1
index 780b596..b5fadf4 100644
@@ -366,8 +366,12 @@ HOST_DIR := $(call qstrip,$(BR2_HOST_DIR))
 # foo-config scripts for the target go here
 FOO_CONFIG_DIR := $(HOST_DIR)/opt/foo-config
 
+# Host PATH is just BR_PATH, but target PATH must find the foo-config
+# scripts first.
 # Quotes are needed for spaces and all in the original PATH content.
-BR_PATH = "$(HOST_DIR)/bin:$(HOST_DIR)/sbin:$(HOST_DIR)/usr/bin:$(HOST_DIR)/usr/sbin:$(PATH)"
+BR_PATH = $(HOST_DIR)/bin:$(HOST_DIR)/sbin:$(HOST_DIR)/usr/bin:$(HOST_DIR)/usr/sbin:$(PATH)
+HOST_PATH = "$(BR_PATH)"
+TARGET_PATH = "$(FOO_CONFIG_DIR):$(BR_PATH)"
 
 # Location of a file giving a big fat warning that output/target
 # should not be used as the root filesystem.
Signature · 1 line
1.9.1
#7 lore raw

RFC PATCH 5/8 fs: use HOST_PATH

In reply to Yann E. MORIN
Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
Cc Samuel Martin <[email protected]>
---
 fs/common.mk    | 6 +++---
 fs/ext2/ext2.mk | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)
fs/common.mk +3 -3
index 528e194..b513f63 100644
@@ -90,14 +90,14 @@ ifneq ($$(ROOTFS_USERS_TABLES),)
 	cat $$(ROOTFS_USERS_TABLES) >> $$(USERS_TABLE)
 endif
 	printf '$$(subst $$(sep),\n,$$(PACKAGES_USERS))' >> $$(USERS_TABLE)
-	PATH=$$(BR_PATH) $$(TOPDIR)/support/scripts/mkusers $$(USERS_TABLE) $$(TARGET_DIR) >> $$(FAKEROOT_SCRIPT)
+	PATH=$$(HOST_PATH) $$(TOPDIR)/support/scripts/mkusers $$(USERS_TABLE) $$(TARGET_DIR) >> $$(FAKEROOT_SCRIPT)
 	echo "$$(ROOTFS_$(2)_CMD)" >> $$(FAKEROOT_SCRIPT)
 	chmod a+x $$(FAKEROOT_SCRIPT)
-	PATH=$$(BR_PATH) $$(HOST_DIR)/usr/bin/fakeroot -- $$(FAKEROOT_SCRIPT)
+	PATH=$$(HOST_PATH) $$(HOST_DIR)/usr/bin/fakeroot -- $$(FAKEROOT_SCRIPT)
 	$$(INSTALL) -m 0644 support/misc/target-dir-warning.txt $$(TARGET_DIR_WARNING_FILE)
 	- at rm -f $$(FAKEROOT_SCRIPT) $$(FULL_DEVICE_TABLE)
 ifneq ($$(ROOTFS_$(2)_COMPRESS_CMD),)
-	PATH=$$(BR_PATH) $$(ROOTFS_$(2)_COMPRESS_CMD) $$@ > $$@$$(ROOTFS_$(2)_COMPRESS_EXT)
+	PATH=$$(HOST_PATH) $$(ROOTFS_$(2)_COMPRESS_CMD) $$@ > $$@$$(ROOTFS_$(2)_COMPRESS_EXT)
 endif
 	$$(foreach hook,$$(ROOTFS_$(2)_POST_GEN_HOOKS),$$(call $$(hook))$$(sep))
 
fs/ext2/ext2.mk +1 -1
index 7417f81..ab876b7 100644
@@ -31,7 +31,7 @@ endif
 ROOTFS_EXT2_DEPENDENCIES = host-mke2img
 
 define ROOTFS_EXT2_CMD
-	PATH=$(BR_PATH) mke2img -d $(TARGET_DIR) $(EXT2_OPTS) -o $@
+	PATH=$(HOST_PATH) mke2img -d $(TARGET_DIR) $(EXT2_OPTS) -o $@
 endef
 
 rootfs-ext2-symlink:
Signature · 1 line
1.9.1
#8 lore raw

RFC PATCH 6/8 packages: use HOST_PATH

In reply to Yann E. MORIN
Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
Cc Samuel Martin <[email protected]>
---
 package/Makefile.in   | 6 +++---
 package/pkg-cmake.mk  | 2 +-
 package/pkg-python.mk | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
package/Makefile.in +3 -3
index 82a66c2..7517a62 100644
@@ -272,7 +272,7 @@ TARGET_MAKE_ENV = PATH=$(BR_PATH)
 
 
 HOST_CONFIGURE_OPTS = \
-	PATH=$(BR_PATH) \
+	PATH=$(HOST_PATH) \
 	AR="$(HOSTAR)" \
 	AS="$(HOSTAS)" \
 	LD="$(HOSTLD)" \
@@ -295,7 +295,7 @@ HOST_CONFIGURE_OPTS = \
 	INTLTOOL_PERL=$(PERL)
 
 HOST_MAKE_ENV = \
-	PATH=$(BR_PATH) \
+	PATH=$(HOST_PATH) \
 	PKG_CONFIG="$(PKG_CONFIG_HOST_BINARY)" \
 	PKG_CONFIG_SYSROOT_DIR="/" \
 	PKG_CONFIG_LIBDIR="$(HOST_DIR)/usr/lib/pkgconfig"
@@ -305,7 +305,7 @@ HOST_MAKE_ENV = \
 # explicitly pass it to user-supplied external hooks (eg. post-build,
 # post-images)
 EXTRA_ENV = \
-	PATH=$(BR_PATH) \
+	PATH=$(HOST_PATH) \
 	BR2_DL_DIR=$(BR2_DL_DIR) \
 	BUILD_DIR=$(BUILD_DIR) \
 	BR2_EXTERNAL=$(BR2_EXTERNAL)
package/pkg-cmake.mk +1 -1
index 81dcfcc..101a551 100644
@@ -109,7 +109,7 @@ define $(2)_CONFIGURE_CMDS
 	(mkdir -p $$($$(PKG)_BUILDDIR) && \
 	cd $$($$(PKG)_BUILDDIR) && \
 	rm -f CMakeCache.txt && \
-	PATH=$$(BR_PATH) \
+	PATH=$$(HOST_PATH) \
 	$$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
 		-DCMAKE_INSTALL_SO_NO_EXE=0 \
 		-DCMAKE_FIND_ROOT_PATH="$$(HOST_DIR)" \
package/pkg-python.mk +2 -2
index b7a702d..d94a485 100644
@@ -43,7 +43,7 @@ PKG_PYTHON_DISTUTILS_INSTALL_STAGING_OPTS = \
 
 # Host distutils-based packages
 HOST_PKG_PYTHON_DISTUTILS_ENV = \
-	PATH=$(BR_PATH)
+	PATH=$(HOST_PATH)
 
 HOST_PKG_PYTHON_DISTUTILS_INSTALL_OPTS = \
 	--prefix=$(HOST_DIR)/usr
@@ -70,7 +70,7 @@ PKG_PYTHON_SETUPTOOLS_INSTALL_STAGING_OPTS = \
 
 # Host setuptools-based packages
 HOST_PKG_PYTHON_SETUPTOOLS_ENV = \
-	PATH=$(BR_PATH)
+	PATH=$(HOST_PATH)
 
 HOST_PKG_PYTHON_SETUPTOOLS_INSTALL_OPTS = \
 	--prefix=$(HOST_DIR)/usr
Signature · 1 line
1.9.1
#9 lore raw

RFC PATCH 7/8 packages: use TARGET_PATH

In reply to Yann E. MORIN

Note that libhid should no longer need that trick, but this woill be fixed independently in a follow-up patch.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
Cc Samuel Martin <[email protected]>
---
 package/Makefile.in          | 4 ++--
 package/faifa/faifa.mk       | 2 +-
 package/freetype/freetype.mk | 2 +-
 package/gpm/gpm.mk           | 2 +-
 package/kodi/kodi.mk         | 2 +-
 package/libhid/libhid.mk     | 2 +-
 package/pkg-cmake.mk         | 2 +-
 package/pkg-python.mk        | 4 ++--
 package/sdl/sdl.mk           | 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)
package/Makefile.in +2 -2
index 7517a62..e211001 100644
@@ -231,7 +231,7 @@ export PERL=$(shell which perl)
 export PERL5LIB=$(HOST_DIR)/usr/lib/perl
 
 TARGET_CONFIGURE_OPTS = \
-	PATH=$(BR_PATH) \
+	PATH=$(TARGET_PATH) \
 	AR="$(TARGET_AR)" \
 	AS="$(TARGET_AS)" \
 	LD="$(TARGET_LD)" \
@@ -268,7 +268,7 @@ TARGET_CONFIGURE_OPTS = \
 	STAGING_DIR="$(STAGING_DIR)" \
 	INTLTOOL_PERL=$(PERL)
 
-TARGET_MAKE_ENV = PATH=$(BR_PATH)
+TARGET_MAKE_ENV = PATH=$(TARGET_PATH)
 
 
 HOST_CONFIGURE_OPTS = \
package/faifa/faifa.mk +1 -1
index a56a8c0..1c9ccb5 100644
@@ -18,7 +18,7 @@ FAIFA_MAKE_OPTS += GIT_REV=$(FAIFA_VERSION)
 # installation commands.
 
 define FAIFA_RUN_AUTOGEN
-	cd $(@D) && PATH=$(BR_PATH) ./autogen.sh
+	cd $(@D) && PATH=$(TARGET_PATH) ./autogen.sh
 endef
 FAIFA_PRE_CONFIGURE_HOOKS += FAIFA_RUN_AUTOGEN
 
package/freetype/freetype.mk +1 -1
index fa11b0c..a611b83 100644
@@ -23,7 +23,7 @@ HOST_FREETYPE_CONF_OPTS = --without-zlib --without-bzip2 --without-png
 # even AUTORECONF with _OPTS doesn't do it properly.
 # POST_PATCH is because we still need to patch libtool after the regen.
 define FREETYPE_RUN_AUTOGEN
-	cd $(@D) && PATH=$(BR_PATH) ./autogen.sh
+	cd $(@D) && PATH=$(TARGET_PATH) ./autogen.sh
 endef
 FREETYPE_POST_PATCH_HOOKS += FREETYPE_RUN_AUTOGEN
 HOST_FREETYPE_POST_PATCH_HOOKS += FREETYPE_RUN_AUTOGEN
package/gpm/gpm.mk +1 -1
index 6d3b5d2..e753ce7 100644
@@ -36,7 +36,7 @@ GPM_CONF_OPTS = --without-curses
 # configure is missing but gpm seems not compatible with our autoreconf
 # mechanism so we have to do it manually instead of using GPM_AUTORECONF = YES
 define GPM_RUN_AUTOGEN
-	cd $(@D) && PATH=$(BR_PATH) ./autogen.sh
+	cd $(@D) && PATH=$(TARGET_PATH) ./autogen.sh
 endef
 GPM_PRE_CONFIGURE_HOOKS += GPM_RUN_AUTOGEN
 
package/kodi/kodi.mk +1 -1
index bf3aa7a..95442ad 100644
@@ -224,7 +224,7 @@ endif
 define KODI_BOOTSTRAP
 	$(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)/tools/depends/native/JsonSchemaBuilder
 	$(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)/tools/depends/native/TexturePacker
-	cd $(@D) && PATH=$(BR_PATH) ./bootstrap
+	cd $(@D) && PATH=$(TARGET_PATH) ./bootstrap
 endef
 KODI_PRE_CONFIGURE_HOOKS += KODI_BOOTSTRAP
 
package/libhid/libhid.mk +1 -1
index 8b3cb2a..92a3049 100644
@@ -13,7 +13,7 @@ LIBHID_LICENSE = GPLv2
 LIBHID_LICENSE_FILES = COPYING
 # configure runs libusb-config for cflags/ldflags. Ensure it picks up
 # the target version
-LIBHID_CONF_ENV = PATH=$(STAGING_DIR)/usr/bin:$(BR_PATH)
+LIBHID_CONF_ENV = PATH=$(STAGING_DIR)/usr/bin:$(TARGET_PATH)
 LIBHID_CONF_OPTS = \
 	--disable-swig \
 	--disable-werror \
package/pkg-cmake.mk +1 -1
index 101a551..ddef2d8 100644
@@ -84,7 +84,7 @@ define $(2)_CONFIGURE_CMDS
 	(mkdir -p $$($$(PKG)_BUILDDIR) && \
 	cd $$($$(PKG)_BUILDDIR) && \
 	rm -f CMakeCache.txt && \
-	PATH=$$(BR_PATH) \
+	PATH=$$(TARGET_PATH) \
 	$$($$(PKG)_CONF_ENV) $$(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
 		-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
 		-DCMAKE_BUILD_TYPE=$$(if $$(BR2_ENABLE_DEBUG),Debug,Release) \
package/pkg-python.mk +2 -2
index d94a485..e0d9650 100644
@@ -22,7 +22,7 @@
 
 # Target distutils-based packages
 PKG_PYTHON_DISTUTILS_ENV = \
-	PATH=$(BR_PATH) \
+	PATH=$(TARGET_PATH) \
 	CC="$(TARGET_CC)" \
 	CFLAGS="$(TARGET_CFLAGS)" \
 	LDFLAGS="$(TARGET_LDFLAGS)" \
@@ -50,7 +50,7 @@ HOST_PKG_PYTHON_DISTUTILS_INSTALL_OPTS = \
 
 # Target setuptools-based packages
 PKG_PYTHON_SETUPTOOLS_ENV = \
-	PATH=$(BR_PATH) \
+	PATH=$(TARGET_PATH) \
 	PYTHONPATH="$(if $(BR2_PACKAGE_PYTHON3),$(PYTHON3_PATH),$(PYTHON_PATH))" \
 	_python_sysroot=$(STAGING_DIR) \
 	_python_prefix=/usr \
package/sdl/sdl.mk +1 -1
index cc1ad06..5896fb1 100644
@@ -14,7 +14,7 @@ SDL_INSTALL_STAGING = YES
 # we're patching configure.in, but package cannot autoreconf with our version of
 # autotools, so we have to do it manually instead of setting SDL_AUTORECONF = YES
 define SDL_RUN_AUTOGEN
-	cd $(@D) && PATH=$(BR_PATH) ./autogen.sh
+	cd $(@D) && PATH=$(TARGET_PATH) ./autogen.sh
 endef
 
 SDL_PRE_CONFIGURE_HOOKS += SDL_RUN_AUTOGEN
Signature · 1 line
1.9.1
#10 lore raw

RFC PATCH 7/8 packages: use TARGET_PATH

Hi Yann,

Quoted 2 lines · Yann E. MORIN

Note that libhid should no longer need that trick, but this woill be fixed independently in a follow-up patch.

So can BR_PATH be removed entirely from top Makefile after this patch?

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#11 lore raw

RFC PATCH 7/8 packages: use TARGET_PATH

Baruch, All,

On 2015-12-21 20:44 +0200, Baruch Siach spake thusly:

Quoted 5 lines · Yann E. MORIN
Quoted 2 lines

Note that libhid should no longer need that trick, but this woill be fixed independently in a follow-up patch.

So can BR_PATH be removed entirely from top Makefile after this patch?

I wondered about that.

Still, I think we should keep it, in case we need to update both PATHs with new entries.

We could obviously do:

    TARGET_PATH = $(FOO_CONFIG_DIR):$(HOST_PATH)

but that would not fly too far if we need to add dirs to HOST_PATH that should not be in TARGET_PATH.

So I prefer to keep BR_PATH (which we could rename as BR_COMMON_PATH).

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.  |
'------------------------------^-------^------------------^--------------------'
#12 lore raw

RFC PATCH 8/8 package/libhid: no need for custom PATH

In reply to Yann E. MORIN

Now that we have all the target foo-config scripts early in the PATH, we no longer need a cutom PATH.

Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
---
 package/libhid/libhid.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
package/libhid/libhid.mk +1 -3
index 92a3049..3c65814 100644
@@ -11,9 +11,7 @@ LIBHID_INSTALL_STAGING = YES
 LIBHID_AUTORECONF = YES
 LIBHID_LICENSE = GPLv2
 LIBHID_LICENSE_FILES = COPYING
-# configure runs libusb-config for cflags/ldflags. Ensure it picks up
-# the target version
-LIBHID_CONF_ENV = PATH=$(STAGING_DIR)/usr/bin:$(TARGET_PATH)
+
 LIBHID_CONF_OPTS = \
 	--disable-swig \
 	--disable-werror \
Signature · 1 line
1.9.1
#13 lore raw

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

In reply to Yann E. MORIN

Yann,

Quoted 11 lines · Yann E. MORIN

This RFC series is an attempt at solving once and for all the problem we encounter with foo-config scripts.

The foo-config scripts are usually installed in staging, so are out of the PATH. However, most packages will just simply want to run them, and most are not configurable in where to look for that script and just expect to find them in the PATH.

Up until now, we used to patch those packages so that they accept an environment variable.

Quoted 7 lines

Arnout has suggested [0] that we move all the target-related foo-config scripts early in the PATH, so that they are found before the host ones and before the system ones.

This would allow us to drop our local patches, and to no longer set the custom FOO_CONFIG or the ac_cv_foo_config variables from our package recipes.

Unfortunately, I believe it doesn't work completely, because there are some <foo>-config scripts that are not listed in <pkg>_CONFIG_SCRIPTS because they are for some reason not compatible with the fixup that we do. One example that comes to mind is python-*config (they are written in shell but don't follow the usual pattern). I believe there might be other cases as well.

Also, this solution doesn't solve the (admittedly unlikely) case of a package calling /usr/bin/<foo>-config directly.

But I agree that it might solve many of the usual cases. I don't know if the additional complexity of yet another special mechanism really makes it worth it. I'd like to hear from Peter about this.

Thomas

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

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Thomas, All,

On 2015-12-21 23:20 +0100, Thomas Petazzoni spake thusly:

Quoted 20 lines · Yann E. MORIN
Quoted 11 lines

This RFC series is an attempt at solving once and for all the problem we encounter with foo-config scripts.

The foo-config scripts are usually installed in staging, so are out of the PATH. However, most packages will just simply want to run them, and most are not configurable in where to look for that script and just expect to find them in the PATH.

Up until now, we used to patch those packages so that they accept an environment variable.

Quoted 7 lines

Arnout has suggested [0] that we move all the target-related foo-config scripts early in the PATH, so that they are found before the host ones and before the system ones.

This would allow us to drop our local patches, and to no longer set the custom FOO_CONFIG or the ac_cv_foo_config variables from our package recipes.

Quoted 5 lines

Unfortunately, I believe it doesn't work completely, because there are some <foo>-config scripts that are not listed in <pkg>_CONFIG_SCRIPTS because they are for some reason not compatible with the fixup that we do. One example that comes to mind is python-*config (they are written in shell but don't follow the usual pattern).

And how do we handle them today? If we don't do anything about it, then this series would indeed not solve those, but it would not break it either, since it would already be broken today.

Unless we do have code to manually install them in $(HOST_DIR)/usr/bin ?

Quoted 2 lines

I believe there might be
other cases as well.

Again, what are we doing for those today?

Quoted 2 lines

Also, this solution doesn't solve the (admittedly unlikely) case of a package calling /usr/bin/<foo>-config directly.

Indeed. But it is already broken today, and the series does not break it any more.

Quoted 3 lines

But I agree that it might solve many of the usual cases. I don't know if the additional complexity of yet another special mechanism really makes it worth it. I'd like to hear from Peter about this.

Yes, this series is really just an RFC. It was relatively easy to do (even a bit easier than what I expected, aha!), so I just spun it on the list just to "feel the temperature".

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.  |
'------------------------------^-------^------------------^--------------------'
#15 lore raw

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Yann,

Quoted 5 lines · Yann E. MORIN

And how do we handle them today? If we don't do anything about it, then this series would indeed not solve those, but it would not break it either, since it would already be broken today.

Unless we do have code to manually install them in $(HOST_DIR)/usr/bin ?

What? No, we are just installing them in $(STAGING_DIR), like all libraries. You can look at package/rtai/rtai.mk for an example.

Quoted 5 lines
Quoted 2 lines

Also, this solution doesn't solve the (admittedly unlikely) case of a package calling /usr/bin/<foo>-config directly.

Indeed. But it is already broken today, and the series does not break it any more.

It is not broken today. Such special *-config scripts get naturally installed in $(STAGING_DIR), they might be fixed up by a patch or some custom hook. And then on the consumer side, we pass some environment variable or other trick to get the consumer build system to use this specific -config script rather than the one in the PATH. Nothing special.

Thomas

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

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Thomas, All,

On 2015-12-21 23:34 +0100, Thomas Petazzoni spake thusly:

Quoted 9 lines · Yann E. MORIN
Quoted 5 lines

And how do we handle them today? If we don't do anything about it, then this series would indeed not solve those, but it would not break it either, since it would already be broken today.

Unless we do have code to manually install them in $(HOST_DIR)/usr/bin ?

What? No, we are just installing them in $(STAGING_DIR), like all libraries. You can look at package/rtai/rtai.mk for an example.

That one is interesting, indeed. We "fix" rtai-config in-place in staging, but then we never pass $(STAGING_DIR)/usr/bin/rtai-config to any variable of any package, which means that any consumer of rtai-config, if any, is called with $(STAGING_DIR)/usr/bin in its PATH.

I think this is an abomination. There are three cases there:

- cross-compiling for a different architecture with shared libraries:
this is not really a problem, binaries in there will not work; yet, this might still cause problems, because there might be binaries in there that would shadow those of the host, and that would be a problem.

- cross-compiling for the same architecture: binaries in staging would probably work if the host system is recent enough that the C library id "compatible" (same or newer glibc on the host) or if doing a static build.

- cross-compiling with static libs: damn, that one would be awfully trricky to debug. For example, my machine is setup to run qemu-user for some architectures, so I'd totaly be able to run ARM binaries on my build machine. Fortunately, this is a rare-enough case that we were not caught by it yet...

And we indeed do such abonminations. For example, the libhid stuff that I already fixed in my series.

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

Also, this solution doesn't solve the (admittedly unlikely) case of a package calling /usr/bin/<foo>-config directly.

Indeed. But it is already broken today, and the series does not break it any more.

Quoted 6 lines

It is not broken today. Such special *-config scripts get naturally installed in $(STAGING_DIR), they might be fixed up by a patch or some custom hook. And then on the consumer side, we pass some environment variable or other trick to get the consumer build system to use this specific -config script rather than the one in the PATH. Nothing special.

Then those patch-or-hook fixups should be complemented by a post-install hook that also installs the -config script in the newly-introduced FOO_CONFIG_DIR.

Again, nothing that this series would *break*; existing "workarounds" would continue to work as-is. It's only a new opportunity to cleanup the mess, but will need much more pathces later on.

Ah, that's probably what I forgot to write in my cover later: this 8-patch series only introduces the "infra" and does not actually fix the packages, or undo our workarounds, or removes our patches, of add new fixes. Hmm. Well, actually I did:

When/if the topic is accepted (and the series is fixed after the reviews), we can then (un)fix / (un)patch packages in follow-up patches.

Or maybe I completely missed the point...

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.  |
'------------------------------^-------^------------------^--------------------'
#17 lore raw

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Hello,

Quoted 4 lines · Yann E. MORIN

That one is interesting, indeed. We "fix" rtai-config in-place in staging, but then we never pass $(STAGING_DIR)/usr/bin/rtai-config to any variable of any package, which means that any consumer of rtai-config, if any, is called with $(STAGING_DIR)/usr/bin in its PATH.

Absolutely not.

There are no packages in Buildroot that use the RTAI libraries. The rtai-config script in $(STAGING_DIR) is meant to be used:

1/ by custom packages (i.e not in Buildroot mainline)

2/ by people building their stuff outside of Buildroot

Quoted 1 line

I think this is an abomination. There are three cases there:

There is absolutely no abomination here. This is a regular *-config script, installed in STAGING_DIR like any other. It is just not used by any package in the upstream Buildroot.

Quoted 10 lines
Quoted 6 lines

It is not broken today. Such special *-config scripts get naturally installed in $(STAGING_DIR), they might be fixed up by a patch or some custom hook. And then on the consumer side, we pass some environment variable or other trick to get the consumer build system to use this specific -config script rather than the one in the PATH. Nothing special.

Then those patch-or-hook fixups should be complemented by a post-install hook that also installs the -config script in the newly-introduced FOO_CONFIG_DIR.

Correct.

Quoted 4 lines

Again, nothing that this series would *break*; existing "workarounds" would continue to work as-is. It's only a new opportunity to cleanup the mess, but will need much more pathces later on.

Quoted 8 lines

Ah, that's probably what I forgot to write in my cover later: this 8-patch series only introduces the "infra" and does not actually fix the packages, or undo our workarounds, or removes our patches, of add new fixes. Hmm. Well, actually I did:

When/if the topic is accepted (and the series is fixed after the reviews), we can then (un)fix / (un)patch packages in follow-up patches.

Yes, yes, this is fully understood, I do understand that we will be able to remove a number of patches, or custom variable passing.

Thomas

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

cover core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)

Thomas, All,

On 2015-12-22 11:53 +0100, Thomas Petazzoni spake thusly:

Quoted 14 lines · Yann E. MORIN
Quoted 5 lines

That one is interesting, indeed. We "fix" rtai-config in-place in staging, but then we never pass $(STAGING_DIR)/usr/bin/rtai-config to any variable of any package, which means that any consumer of rtai-config, if any, is called with $(STAGING_DIR)/usr/bin in its PATH.

Absolutely not.

There are no packages in Buildroot that use the RTAI libraries. The rtai-config script in $(STAGING_DIR) is meant to be used:

1/ by custom packages (i.e not in Buildroot mainline)

Quoted 7 lines

2/ by people building their stuff outside of Buildroot

Quoted 1 line

I think this is an abomination. There are three cases there:

There is absolutely no abomination here. This is a regular *-config script, installed in STAGING_DIR like any other. It is just not used by any package in the upstream Buildroot.

Oh, sorry, what I meant is: having staging/usr/bin in the PATH is an abomination.

Of course, the rtai-config script is not the abomination I was referring too. My bad, I was not carefull enough in proof-reading what I wrote.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

It is not broken today. Such special *-config scripts get naturally installed in $(STAGING_DIR), they might be fixed up by a patch or some custom hook. And then on the consumer side, we pass some environment variable or other trick to get the consumer build system to use this specific -config script rather than the one in the PATH. Nothing special.

Quoted 11 lines
Quoted 3 lines

Then those patch-or-hook fixups should be complemented by a post-install hook that also installs the -config script in the newly-introduced FOO_CONFIG_DIR.

Correct.

Quoted 5 lines

Again, nothing that this series would *break*; existing "workarounds" would continue to work as-is. It's only a new opportunity to cleanup the mess, but will need much more pathces later on.

Ah, that's probably what I forgot to write in my cover later: this

s/later/letter/ Damit... :-)

Cheers! ;-)

Regards,
Yann E. MORIN.

Quoted 16 lines
Quoted 7 lines

8-patch series only introduces the "infra" and does not actually fix the packages, or undo our workarounds, or removes our patches, of add new fixes. Hmm. Well, actually I did:

When/if the topic is accepted (and the series is fixed after the reviews), we can then (un)fix / (un)patch packages in follow-up patches.

Yes, yes, this is fully understood, I do understand that we will be able to remove a number of patches, or custom variable passing.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
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.  |
'------------------------------^-------^------------------^--------------------'