All of lore.kernel.org
 help / color / mirror / Atom feed
From: ChenQi <Qi.Chen@windriver.com>
To: Qiang Yu <yuq825@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: When to create a new build directory for yocto?
Date: Mon, 1 Dec 2014 15:23:16 +0800	[thread overview]
Message-ID: <547C1764.7080207@windriver.com> (raw)
In-Reply-To: <CAKGbVbvV5Hio1xbyEaf1Kk_jOMnGys0Disr66ej9zuO+YY3RFg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

On 12/01/2014 03:04 PM, Qiang Yu wrote:
> What about MACHINE_FEATURES and IMAGE_FEATURES?
>

IMAGE_FEATURES is OK.
MACHINE_FEATURES is like DISTRO_FEATURES. Things are not ensured to work 
correctly if you change it in the same build directory.

If I were you, I would jut let builds to share sstate and downloads and 
use different build directories for each combination of 'machine + 
distro + feature'.
E.g.
build-qemux86-64-poky-systemd-pam
build-qemux86-64-poky-systemd
build-qemux86-64-poky-sysvinit-pam
....

This would ensure a clean upgrade path.

//Chen Qi

>
> On Mon, Dec 1, 2014 at 1:28 PM, ChenQi <Qi.Chen@windriver.com 
> <mailto:Qi.Chen@windriver.com>> wrote:
>
>     On 12/01/2014 12:45 PM, Qiang Yu wrote:
>>
>>
>>         It's possible that you are using (or might use) different
>>         layer configurations for different builds.
>>         One build might have a bbappend file that another build
>>         doesn't need.
>>
>>     Yes, you are right. I use different conf/bblayers.conf for
>>     different SOC. But within the same SOC's different output
>>     (board image, SDK), I just change MACHINE and SDKMACHINE. Is it
>>     safe to build all outputs of the same SOC
>>     in one build dir?
>
>     Yes.
>
>>         Also, different builds may have different DISTRO_FEATURES.
>>         Thus, having different deploy directories is better.
>>         Otherwise, your package feeds might be broken. And you would
>>         suffer trying to maintain it.
>>
>>     You mean I can't build two output with different DISTRO_FEATURES
>>     in the same build dir.
>>     Any other config var? What about MACHINE and SDKMACHINE?
>
>     Yocto doesn't ensure that changing distro features in the same
>     build directory works.
>     It might work, but it's also possible that it doesn't.
>
>     Changing MACHINE and SDKMACHINE is OK.
>
>     //Chen Qi
>
>


[-- Attachment #2: Type: text/html, Size: 5550 bytes --]

  reply	other threads:[~2014-12-01  7:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-30  4:49 When to create a new build directory for yocto? Qiang Yu
2014-11-30  8:03 ` ChenQi
2014-11-30 14:28   ` Qiang Yu
2014-12-01  1:37     ` Qiang Yu
     [not found]   ` <CAKGbVbuLb-fzeGp78NxWYysVru=cweptGcjq2AuzVath+DC57g@mail.gmail.com>
     [not found]     ` <547BCC00.2070106@windriver.com>
2014-12-01  3:01       ` Qiang Yu
2014-12-01  3:27         ` ChenQi
2014-12-01  4:45           ` Qiang Yu
2014-12-01  5:28             ` ChenQi
2014-12-01  7:04               ` Qiang Yu
2014-12-01  7:23                 ` ChenQi [this message]
     [not found]                 ` <547C196A.8080208@windriver.com>
2014-12-01  8:13                   ` Qiang Yu

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=547C1764.7080207@windriver.com \
    --to=qi.chen@windriver.com \
    --cc=yocto@yoctoproject.org \
    --cc=yuq825@gmail.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 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.