[OE-core] [RFC] Add something like bitbake -cmenuconfig <recipe> ?

[Paul Eggleton]

On Monday 18 May 2015 08:15:05 Christopher Larson wrote:
> On Mon, May 18, 2015 at 5:04 AM, Paul Eggleton <
> paul.eggleton at linux.intel.com> wrote:
> > On Monday 18 May 2015 08:52:04 Otavio Salvador wrote:
> > > On Mon, May 18, 2015 at 5:45 AM, Paul Eggleton
> > > <paul.eggleton at linux.intel.com> wrote:
> > > > 
> > > > On Monday 18 May 2015 09:52:50 Robert Yang wrote:
> > > >> On 05/17/2015 05:34 AM, Richard Purdie wrote:
> > > >> > On Fri, 2015-05-15 at 10:35 +0800, Robert Yang wrote:
> > > >> >> Is is useful/possible if we add something like bitbake <recipe>
> > > >> >> -cmenuconfig, just like kernel's make menuconfig ?
> > > >> >> 
> > > >> >> We can use the menuconfig to config the vars such as MACHINE,
> > > >> >> DL_DIR, DISTRO_FEATURES, MACHINE_FEATURES and all the variables
> > > >> >> which are configurable, I think that this would help the newbie a
> > > >> >> lot.
> > > >> >> 
> > > >> >> I think that we can add a menuconfig.bbclass (or other names) to
> > > >> >> do this, and I'd like to work on it.
> > > >> > 
> > > >> > Why would you want to specify a <recipe> when configuring MACHINE?
> > > >> > I understand why you're thinking this but it isn't well thought out
> > > >> > and in this form would confuse users more than help them.
> > > >> > 
> > > >> > I don't think the system will even parse without a valid MACHINE,
> > > >> > let alone execute tasks.
> > > >> 
> > > >> I meant that we need something to help configure the build easier, it
> > > >> can generate something like local.conf.append, not configure the
> > > >> recipe.
> > > >>
> > > >> The example "bitbake <recipe> -cmenuconfig" wasn't right enough, it's
> > > >> just a rough thought, we can use the current default local.conf
> > > >> (MACHINE = qemux86) to make system parse.
> > > >> 
> > > >> The problem is that we have many bbclasses in oe-core, a lot of them
> > > >> has specify configurations, and also a lot of vars in the conf file
> > > >> such as bitbake.conf, it's not easy to know how and what to config,
> > > >> especially, for newbies. The "bitbake -cmenuconfig" maybe not a good
> > > >> idea, I think that we need something to help config the build
> > > >> (generate local.conf) easier, do you have any suggestions, please ?
> > > > 
> > > > This is likely the direction we will be going in with the Toaster web
> > > > UI - with a web-based tool we can present a much friendlier interface
> > > > and have the chance to link to other information, for example we can
> > > > link to the appropriate manual section for individual variables (and
> > > > in future error messages, classes, etc.), analyse the output of the
> > > > build, manage multiple sets of configuration, etc. These are things
> > > > that would be difficult to do practically from the command line.
> > > 
> > > Toaster is nice but we shouldn't stop improving cmdline use as the
> > > first won't work for some use-cases.
> > 
> > Sure, I'm pointing out that this kind of thing is being worked on in a
> > slightly different context, it's not that nothing is being done in this
> > area.
> 
> A good first step for both may be to add more typing information to the
> metadata, so the UI can present something more intelligent than a bunch of
> text boxes for text input. I expect that would be useful for any
> configuration UI, whether toaster or console.

Indeed, this is something I'd like to see as well. There are already 
situations where we need to know the type of various variables (e.g. in 
buildhistory, where we have some of the variable typing hardcoded in the 
absence of proper definition within the metadata).

> I’d certainly find a curses / menuconfig style interface to be interesting,
> I’m sure there are folks who would find it useful, as long as it’s done
> well.

Sure, I wouldn't object to it either, but the important thing is someone not 
only needs to create it, but also maintain it in the future. Ideally it would 
also make use of some underlying definitions / code that would be re-usable 
elsewhere (as you're suggesting).

> My question would be, how does the UI determine what variables to present?
> Do we hardcode the list of variables they might want to edit, or provide
> that information in the metadata in some fashion?

I'd certainly prefer to define as much as possible in the metadata. Truth be 
told we have defined a bit more than I'd like in the way of OE-specific 
knowledge in Toaster itself; my intent was that we'd come back and clean up a 
lot of it later where practical, but of course that does mean improving what 
we expose on the metadata side, and sometimes that's really quite difficult.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre