Skip to contentSkip to conversation

Add dummy tools to help identify needed dependencies

PATCH Superseded Peter Kjellerstedt 2 participants 6 messages Feb 28, 2017

v1 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

cover Add dummy tools to help identify needed dependencies

After the introduction of RSS, I still found it hard to get dependencies on some common tools that are typically installed on the build host correct. Using the wrong version of tools like pkg-config, gdbus-codegen and dbus-binding-tool can cause build failures.

To circumvent this, I created dummy versions of the tools that always fail and placed them in the scripts directory. Thus, if the real tool has not been installed in the RSS, the dummy version is used and the build fails. For good measures I even output a message that says what needs to be corrected in the recipe.

Included is also an update to linux-libc-headers as it apparently needs to inherit pkgconfig, which the introduction of the dummy version of pkg-config showed.

//Peter

The following changes since commit 3c83b56309ab419f8cda72c0711479f60f61439a:

bitbake: fetch2/svn: change 'rsh' parameter to 'ssh' (2017-02-23 12:50:17 -0800)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib pkj/dummy_tools
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pkj/dummy_tools

Peter Kjellerstedt (4):
linux-libc-headers: Add inherit of pkgconfig scripts/dbus-binding-tool: Add a dummy version that always fails scripts/gdbus-codegen: Add a dummy version that always fails scripts/pkg-config: Add a dummy version that always fails

 .../linux-libc-headers/linux-libc-headers.inc            |  2 +-
 scripts/dbus-binding-tool                                | 11 +++++++++++
 scripts/gdbus-codegen                                    | 11 +++++++++++
 scripts/pkg-config                                       | 16 ++++++++++++++++
 4 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100755 scripts/dbus-binding-tool
 create mode 100755 scripts/gdbus-codegen
 create mode 100755 scripts/pkg-config
Signature · 1 line
2.9.0
#1 lore raw

PATCH 1/4 linux-libc-headers: Add inherit of pkgconfig

pkg-config is used by the kernel build system when creating the configuration tools.

---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +1 -1
index 30d2243..653a470 100644
@@ -42,7 +42,7 @@ python __anonymous () {
         d.setVar("HEADER_FETCH_VER", "2.6")
 }
 
-inherit kernel-arch
+inherit kernel-arch pkgconfig
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
Signature · 1 line
2.9.0
#2 lore raw

PATCH 2/4 scripts/dbus-binding-tool: Add a dummy version that always fails

In reply to Peter Kjellerstedt

This is intended to catch missing dependencies on the real version.

---
 scripts/dbus-binding-tool | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/dbus-binding-tool
scripts/dbus-binding-tool new file +11 -0
new file mode 100755
index 0000000..2e85987
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'dbus-glib-native'." >&2
+
+exit 1
Signature · 1 line
2.9.0
#3 lore raw

PATCH 3/4 scripts/gdbus-codegen: Add a dummy version that always fails

In reply to Peter Kjellerstedt

This is intended to catch missing dependencies on the real version.

---
 scripts/gdbus-codegen | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100755 scripts/gdbus-codegen
scripts/gdbus-codegen new file +11 -0
new file mode 100755
index 0000000..d91386b
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe DEPENDS on 'glib-2.0-native'." >&2
+
+exit 1
Signature · 1 line
2.9.0
#4 lore raw

PATCH 4/4 scripts/pkg-config: Add a dummy version that always fails

In reply to Peter Kjellerstedt

This is intended to catch missing dependencies on the real version.

---
 scripts/pkg-config | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100755 scripts/pkg-config
scripts/pkg-config new file +16 -0
new file mode 100755
index 0000000..c6376ec
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+# This is a dummy version that always fails. It is intended to catch
+# missing dependencies on the real version.
+
+myname=${0##*/}
+
+echo "The correct version of $myname is not being used!" >&2
+echo "Make sure the recipe inherits 'pkgconfig'." >&2
+
+# Return something that will make the compiler barf. This is for when
+# pkg-config is used directly in a Makefile in a construct like:
+# CFLAGS += $(shell pkg-config --cflags glib-2.0)
+echo "The-correct-version-of-$myname-is-not-being-used"
+
+exit 1
Signature · 1 line
2.9.0
#5 lore raw
In reply to Peter Kjellerstedt
Quoted 4 lines · Peter Kjellerstedt

After the introduction of RSS, I still found it hard to get dependencies on some common tools that are typically installed on the build host correct. Using the wrong version of tools like pkg-config, gdbus-codegen and dbus-binding-tool can cause build failures.

This is indeed still a problem.

I had also discussed this briefly with Richard. We both had the same
idea: manipulate the PATH so that instead of the initial paths it only contains a directory with symlinks to tools which are okay to inherit from the build host. In other words, the basic approach would be to whitelist acceptable tools.

Quoted 5 lines

To circumvent this, I created dummy versions of the tools that always fail and placed them in the scripts directory. Thus, if the real tool has not been installed in the RSS, the dummy version is used and the build fails. For good measures I even output a message that says what needs to be corrected in the recipe.

This is the other approach: blacklisting tools which are known to be problematic.

I suspect the blacklisting approach is going a long way towards solving the problem, but it'll remain uncertain how complete it is. As it is fairly simple, it's probably worth merging until someone has the time to investigate the whitelisting approach further.

Richard had some code for it in some of his experimental branches.

Signature · 6 lines
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.