Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Christopher Larson <clarson@kergoth.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: how does SCR_URI_OVERRIDES_PACKAGE_ARCH affect building tslib?
Date: Fri, 8 Aug 2014 11:14:50 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1408081112180.18468@localhost> (raw)
In-Reply-To: <CABcZANn2DUaCHavWVPhFnoOgEQM9nF8fiWAyfNcD4e5i89xB8A@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2145 bytes --]

On Fri, 8 Aug 2014, Christopher Larson wrote:

>
> On Fri, Aug 8, 2014 at 3:35 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   looking at SRC_URI_OVERRIDES_PACKAGE_ARCH variable, and i notice
> first that there is only one usage of it in all of oe-core (tslib),
> but i'm confused as to what value it has.
>
>   the ref manual reads:
>
> "By default, the OpenEmbedded build system automatically detects
> whether SRC_URI contains files that are machine-specific. If so, the
> build system automatically changes PACKAGE_ARCH. Setting this variable
> to "0" disables this behavior."
>
>   first, i'm not sure what about the tslib SRC_URI appears to be
> machine-specific. also, just for fun, i commented out that line in the
> tslib .bb file, and did a global "bb show" to see what difference it
> made, and i saw no difference at all. so what exactly is the purpose
> of that line in that recipe? what difference should i be able to see
> with versus without it? thanks.
>
> Any file:// file in an SRC_URI can become machine specific if placed
> in a machine subdir in the search path. That said, I don't know why
> the automatic behavior of setting package_arch in that case is
> something that needs to be disabled for tslib. I'd suggest using
> git-blame to examine the commits which added this variable.

  should have done that first thing ... "git blame" shows that line
goes all the way back to 2006, when tslib *did* have machine-specific
files under tslib/. now that that's no longer true, i suspect that
line can be tossed.

  pity ... i was just looking for a single recipe that used
SRC_URI_OVERRIDES_PACKAGE_ARCH, and now i have none. i haz a sad.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

      reply	other threads:[~2014-08-08 15:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 10:35 how does SCR_URI_OVERRIDES_PACKAGE_ARCH affect building tslib? Robert P. J. Day
2014-08-08 14:25 ` Christopher Larson
2014-08-08 15:14   ` Robert P. J. Day [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=alpine.LFD.2.11.1408081112180.18468@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=clarson@kergoth.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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