Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Trevor Woerner <trevor.woerner@linaro.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	 openembedded-core <openembedded-core@lists.openembedded.org>,
	yocto <yocto@yoctoproject.org>
Subject: --conf Was: Features in Yocto Project 1.7
Date: Mon, 24 Mar 2014 20:11:20 -0400	[thread overview]
Message-ID: <5330C9A8.904@linaro.org> (raw)
In-Reply-To: <1395676843.24890.7.camel@ted>

On 03/24/14 12:00, Richard Purdie wrote:
> I think from my perspective, in 1.7 I'd like to see us looking at
> "Developer Workflow".

Maybe I'm using things incorrectly :-)

But I often find that I'm switching between building different images.
For example, one moment I might be building core-image-minimal (CIM),
then later I'll want to build a GUI image with Wayland.

Switching between CIM and the GUI image requires changes to both
conf/local.conf and conf/bblayers.conf. I will either have two separate
sets of files and symlink between them, or I'll need to edit them by
hand to comment/uncomment out various blocks. I often get this wrong and
will need to restart a couple times before the build can hope to
complete successfully.

If I could wish for one workflow change, it would be the ability to
switch between various build configurations with the minimum of fuss:
- maybe the layer information could be contained within the
configuration file, then on the bitbake cmdline I could just say
"bitbake --conf wayland" or "bitbake --conf mycim" and it would know to
find and use conf/wayland.conf or conf/mycim.conf?
- maybe the local.conf could be renamed wayland.conf and the
bblayers.conf could be renamed wayland.bblayers then I could type
"bitbake --conf wayland" and it would know to look for wayland.conf and
wayland.bblayers?

Does this sort of workflow make sense to others? Or have people noticed
this and solved it in some clever way?


  parent reply	other threads:[~2014-03-25  0:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24 16:00 Features in Yocto Project 1.7 Richard Purdie
     [not found] ` <533058C1.3000102@arm.com>
2014-03-24 16:18   ` [yocto] " Richard Purdie
2014-03-24 19:40 ` Rifenbark, Scott M
2014-03-25  0:11 ` Trevor Woerner [this message]
2014-03-25  5:50   ` --conf Was: " Martin Jansa
2014-03-26 14:33     ` Trevor Woerner
2014-03-26 14:38       ` Otavio Salvador
2014-03-26 20:45         ` Nicolas Dechesne
2014-03-27 16:33           ` Trevor Woerner
2014-03-26 14:46       ` Martin Jansa
2014-03-25 12:22 ` Otavio Salvador
2014-03-25 15:14   ` Mark Hatle
2014-03-25 14:31 ` David Nyström
2014-03-25 15:16   ` Mark Hatle
2014-03-25 17:37   ` [yocto] " Philip Balister
2014-03-27 10:47   ` David Nyström
2014-03-28 15:23     ` Otavio Salvador
2014-03-28 18:00       ` David Nystrom

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=5330C9A8.904@linaro.org \
    --to=trevor.woerner@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.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