From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 594CEE0093E; Sun, 30 Nov 2014 23:23:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, * medium trust * [147.11.146.13 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 7E435E0091F for ; Sun, 30 Nov 2014 23:22:58 -0800 (PST) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.9/8.14.5) with ESMTP id sB17MueK027821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 30 Nov 2014 23:22:56 -0800 (PST) Received: from [128.224.162.226] (128.224.162.226) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 30 Nov 2014 23:22:56 -0800 Message-ID: <547C1764.7080207@windriver.com> Date: Mon, 1 Dec 2014 15:23:16 +0800 From: ChenQi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Qiang Yu References: <547ACF5C.8010403@windriver.com> <547BCC00.2070106@windriver.com> <547BE038.8030108@windriver.com> <547BFC98.1050300@windriver.com> In-Reply-To: X-Originating-IP: [128.224.162.226] Cc: yocto@yoctoproject.org Subject: Re: When to create a new build directory for yocto? X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 07:23:00 -0000 Content-Type: multipart/alternative; boundary="------------040200050200010709000905" --------------040200050200010709000905 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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 > 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 > > --------------040200050200010709000905 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
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> 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


--------------040200050200010709000905--