| Summary: | Implement user-wide configuration file | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Hob | Reporter: | Joshua Lock - Disabled <josh> |
| Component: | hob | Assignee: | Shane Wang <shane.wang> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | dongxiao.xu, jessica.zhang, jiajun.xu, poky.bs.watcher, poky.watcher |
| Version: | unspecified | ||
| Target Milestone: | 1.2 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | Done | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 1588 | ||
It looks/sounds like the Hob2 team have figured out a different way to handle this? Yes, to make user settings take effect, we will do the following things:
Instantiate server
|
v
Instantiate cooker <-- data store is created and conf files parsed,
| the emitted events are queued
v
Set up event handlers <-- events are now handled by the server, any
| queued events are ready to be handled too
v
UI created <-- event handling begins here, after various
values are read from the data store,
starting with all of the queued events -
far too late to do anything useful
|
v
re-init cooker <-- With this step, cooker will be initialized with
nothing parsed.
|
v
Set user variables <-- Set the user configuration into the server.
|
v
Parse config files <-- Parse other bitbake configuration files, like
bblayers.conflocal.conf, machine/xxx.conf, etc.
But here is one thing we must follow: all variables that are Hob2 GUI configurable, they should be set value by "?=" or "??=" in configuration files, otherwise, user settings will be overwritten.
refer to 1743 |
The hob should store its configuration in a centralised place such that the user will see the same set of configuration options in the UI on each run. To facilitate this change the UI needs to be able to modify the datastore before configuration files are parsed. Because the data store is initialised and configuration is parsed before the UI is ready to handle events we cannot, currently, directly interact with the data store before it's populated. We should shit around the cooker instantiation such that data store instantiation and configuration parsing is done *after* the UI is ready to handle events. The current state looks something like this: Instantiate server | v Instantiate cooker <-- data store is created and conf files parsed, | the emitted events are queued v Set up event handlers <-- events are now handled by the server, any | queued events are ready to be handled too v UI created <-- event handling begins here, after various values are read from the data store, starting with all of the queued events - far too late to do anything useful I have a branch which adds a DataInitialised event to the Cooker and a QIP patch to add machinery to hob to handle that event and manipulate values in the data store based on a configuration file stored in the users XDG_CONFIG_DIR: https://github.com/incandescant/bitbake/commits/one-config