Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/4] Add dummy tools to help identify needed dependencies
Date: Tue, 28 Feb 2017 16:56:44 +0100	[thread overview]
Message-ID: <1488297404.7785.53.camel@intel.com> (raw)
In-Reply-To: <cover.1488288835.git.pkj@axis.com>

On Tue, 2017-02-28 at 14:35 +0100, Peter Kjellerstedt wrote:
> 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.

> 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.

-- 
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.





      parent reply	other threads:[~2017-02-28 15:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 13:35 [PATCH 0/4] Add dummy tools to help identify needed dependencies Peter Kjellerstedt
2017-02-28 13:35 ` [PATCH 1/4] linux-libc-headers: Add inherit of pkgconfig Peter Kjellerstedt
2017-02-28 13:35 ` [PATCH 2/4] scripts/dbus-binding-tool: Add a dummy version that always fails Peter Kjellerstedt
2017-02-28 13:35 ` [PATCH 3/4] scripts/gdbus-codegen: " Peter Kjellerstedt
2017-02-28 13:35 ` [PATCH 4/4] scripts/pkg-config: " Peter Kjellerstedt
2017-02-28 15:56 ` Patrick Ohly [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1488297404.7785.53.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox