Re: [Openembedded-architecture] [bitbake-devel] proposal: build pipelines in bitbake-setup

Richard Purdie <[email protected]> Thu, 07 May 2026 14:20:24 +0100
Newsgroups org.yoctoproject.lists.yocto,org.openembedded.lists.bitbake-devel
Message-ID <224b7cb95cda25816f49ce2b036a0c9cca437e1e.camel@linuxfoundation.org>
On Thu, 2026-05-07 at 15:13 +0200, Alexander Kanavin via lists.openembedded.org wrote:
> On Thu, 7 May 2026 at 14:37, Ross Burton <[email protected]> wrote:
> 
> > To be honest I think I disagree with you here.  There’s already a
> > load of “build pipeline” tools from sh scripts to Makefiles to the
> > multitude of  task runners written in every language under the run
> > (invoke, rake, etc).
> > 
> > Does the world need another one?
> 
> The idea is that bitbake-setup should help users do something useful
> with a build they set up, by providing a standard UI. You'd type
> $ bitbake-setup run
> and it will give you a selection of what's possible, and then proceed
> to do it. It's the equivalent of 'kas build', just more flexible :)

The trouble is there are multiple things a user may want to do and
which one is a hard choice to make. If you have some narrow layer with
a specific image and application, that is easy. If you have a general
layer like meta-virtualization, it is unclear which target(s) a given
user may want. nodistro/poky face the same challenge, the thing the
user might want "depends".

> If someone has written their pipeline with make or a shell script,
> then bitbake-setup can simply run that (e.g. a pipeline containing a
> single step), but I think there's also value in having 'native'
> support for multi-step pipelines. They're simple (e.g. executable
> commands are static strings that can't be parametrized), and if that's
> not flexible enough, there's indeed plenty of industrial-grade tools.

I believe if we implement and do something, we need to do it well and
it does need to have a specific target/focus and use. If this
functionality is too hard or inappropriate to use for too many of the
application areas, you have to question whether we should be doing it
at all...

Cheers,

Richard