On Wed, Jan 21, 2015 at 01:08:21PM -0600, Derek Foreman wrote: > On 20/01/15 05:30 PM, Bryce Harrington wrote: > > From: "Bryce Harrington" <[email protected]> > > > > Adds weston_config_update(), which parses a condensed string of > > comma-delimited key/value pairs and adds or changes the corresponding > > parameters in the weston_config structure. > > > > Signed-off-by: Bryce Harrington (http://osg.samsung.com) > > <[email protected]> > > Signed-off-by: Bryce Harrington <[email protected]> > > --- > > shared/config-parser.c | 72 > > +++++++++++++++++++++++++++++++++++++++++++++++--- > > shared/config-parser.h | 6 +++++ > > 2 files changed, 75 insertions(+), 3 deletions(-) > > > > diff --git a/shared/config-parser.c b/shared/config-parser.c > > index 78039ba..0b60c2f 100644 > > --- a/shared/config-parser.c > > +++ b/shared/config-parser.c > > @@ -377,6 +377,20 @@ weston_config_get_libexec_dir(void) > > } > > > > struct weston_config * > > +weston_config_create(void) > > +{ > > + struct weston_config *config; > > + > > + config = malloc(sizeof *config); > > + if (config == NULL) > > + return NULL; > > + > > + wl_list_init(&config->section_list); > > + > > + return config; > > +} > > The need for this isn't explained in the commit log... is this intended > to be part of a different patch?
This is just splitting the creation logic out from weston_config_parse(), so it can be used in compositor.c in the next patch. > > +/* Parses a string of the form section.key=value,section.key=value > > + * and updates the provided config. > > + */ > > +bool > > +weston_config_update(struct weston_config *config, char *line) Thanks for reviewing the patchset. I've made the changes in my local tree. But after chatting with you on IRC about patch 4, I'm increasingly thinking this solution might not be the best way to tackle this. As you pointed out, the syntax is going to be inconsistent with the weston.ini, and there's some built-in limitations like not being able to create multiple monitor sections. Since one part of the motivation for the headless testing is to enable synthetic testing of multi-monitor functionality, that's a pretty severe limitation. But beyond this I'm realizing this approach creates some uncertainty. We start with some arbitrary weston.ini, then apply some changes to it via the command line; we don't have a way to easily review what the final configuration was (we could dump the config to log, but that's yet more code...) The alternate solution was to just generate weston.ini files from the tests themselves, and then pass them via a --config-file or --config-path parameter. This sidesteps all the formatting issues and limitations. More importantly, we can directly view the configuration we're sending in. We didn't pursue that approach originally because it sounded like it could result in a lot of extra annoying test maintenance work. But if we can keep the test weston.ini's minimal (i.e. just a section name and the single parameter to change) it shouldn't be that bad. If our needs become more than minimal, we can consider adding some sort of weston.ini file builder. Bryce _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
