[Linaro-validation] Syntax for custom LAVA tests
zygmunt.krynicki at linaro.org
Tue Mar 27 11:48:30 UTC 2012
W dniu 27.03.2012 13:32, Paul Sokolovsky pisze:
> Yong Qin is working on the blueprint
> to add arbitrary custom client-side scripts to Android Build. He
> submitted first implementation of it as
> and documented as
> https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration .
> Unfortunately, I'm not thrilled with that implementation, more
> specifically, its "user interface" (i.e. any parts which user directly
> faces) by the following reasons:
> 1. The idea behind Android Build's build config was that they're short
> and easy for human to parse, essentially one glance-over would enough
> to get a good idea what is built here, even for outsider. Consequently,
> the configs should not be overloaded with details not related to
> building. If there's a need for integration with other systems, we have
> good pattern of externalizing such details and then just referring to
> them with a single variable in a build config.
> 2. The whole approach in
> seems like trying to encode hierarchical structure in the shell syntax,
> which is not much supporting of that. The end result looks pretty much
> like representation of graph structure in raw assembler - it's
> spaghetti mix of data pieces and labels, requiring long time to wrap
> hand around to understand it, and cumbersome and error-prone to write.
> So, I would like to propose alternative syntax solving the issues
> above. I probably should start with saying that if the talk is about
> LAVA, then using native LAVA JSON request immediately comes to mind.
> Well, I guess human-writability wasn't a design goal for that, so I
> skip it. It still makes sense to stick to general-purpose hierarchical
> structure syntax though. Except that JSON has 2 problems: a) it doesn't
> support comments natively, so we'll need to pre-process it; b) error
> reporting/localization may be still no ideal.
Hi, just jumping into the conversation briefly to look at small
technical aspect. I have not really been tracking this command effort
and I don't understand what it's about.
On JSON: I think that comment 2 is inaccurate. We have very precise
syntax error reporting (down to line/column and text range on some
pinpoints the part of json document that does not match the schema, same
for the schema actually).
Anyway, you have my full support for native json formats. I think that
if comments are an issue I can provide a parser that simply ignores
comments. We could then keep the human readable documents and strictly
machine readable, schema-backed data.
> Anyway, here's my try, it is presented as a comment to
> and then full example at
> Let's discuss if that covers our needs and constraints.
> Linaro.org | Open source software for ARM SoCs
> Follow Linaro: http://www.facebook.com/pages/Linaro
> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
> linaro-validation mailing list
> linaro-validation at lists.linaro.org
Linaro Validation Team
More information about the linaro-validation