All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Usage of NATIVE_INSTALL_WORKS
Date: Tue, 17 Aug 2010 12:01:11 -0700	[thread overview]
Message-ID: <4C6ADC77.90903@mentor.com> (raw)
In-Reply-To: <AANLkTimM1KXgWUXHFz+njHmUAMYo75eVYy2J9ATEC0Bw@mail.gmail.com>

Chris Larson wrote:
> On Tue, Aug 17, 2010 at 10:48 AM, Tom Rini <tom_rini@mentor.com> wrote:
> 
>> Chris Larson wrote:
>>
>>> On Mon, Aug 16, 2010 at 4:37 AM, Enrico Scholz <
>>> enrico.scholz@sigma-chemnitz.de> wrote:
>>>
>>>  Hi,
>>>> http://wiki.openembedded.org/index.php/Legacy_staging states that
>>>> NATIVE_INSTALL_WORKS must be set when there is a non trivial
>>>> do_install() function and BBCLASSEXTEND is used.
>>>>
>>>> But
>>>>
>>>> | git grep NATIVE_INSTALL_WORKS conf/ classes/ lib/
>>>>
>>>> shows only one place where this variable is evaluated:
>>>>
>>>> | classes/staging.bbclass:    elif bb.data.getVar('NATIVE_INSTALL_WORKS',
>>>> d, 1) == "1":
>>>> | classes/staging.bbclass-        legacy = False
>>>>
>>>> And there, it is used only in the is_legacy_staging() function, to
>>>> override legacy/non-legacy detection results.
>>>>
>>>>
>>>> Is there still any use for this variable in modern staging?  Or shall it
>>>> be purged from non-legacy recipes?
>>>>
>>>
>>> If you purge it from particular non-legacy recipes, the legacy detection
>>> code will misidentify those as legacy and fail to do the correct thing.
>>>
>> Can we update the wiki page to expand on when this is needed a little bit
>> more then?  My quick read of is_legacy_staging() says that if do_stage is
>> empty (and it should be if you convert from do_stage to do_install right)
>> NATIVE_INSTALL_WORKS shouldn't be needed.
> 
> 
> Removing the do_stage function from the recipe doesn't necessarily result in
> an empty do_stage.  If you look at native.bbclass, you'll see that do_stage
> is do_stage_native.  If your do_stage is do_stage_native and you haven't set
> AUTOTOOLS_NATIVE_STAGE_INSTALL, it'll fall back to legacy staging, at least
> if I'm reading is_legacy_staging correctly.

So, perhaps it's time to convert that real quick?  Or is there some 
reason I'm not seeing as to why we wouldn't want to:
- Change native.bbclass do_stage / do_stage_native to do_install / 
do_install
- Drop NATIVE_INSTALL_WORKS

-- 
Tom Rini
Mentor Graphics Corporation



      reply	other threads:[~2010-08-17 19:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16 11:37 Usage of NATIVE_INSTALL_WORKS Enrico Scholz
2010-08-16 13:58 ` Chris Larson
2010-08-17 17:48   ` Tom Rini
2010-08-17 18:17     ` Chris Larson
2010-08-17 19:01       ` Tom Rini [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=4C6ADC77.90903@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.