On 27 March 2012 06:32, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
Yong Qin is working on the blueprint https://blueprints.launchpad.net/lava-android-test/+spec/modify-android-buil... to add arbitrary custom client-side scripts to Android Build. He submitted first implementation of it as https://code.launchpad.net/~liuyq0307/linaro-android-build-tools/run-custom/... 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:
- 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.
- The whole approach in
https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration 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.
Anyway, here's my try, it is presented as a comment to https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration and then full example at https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration/pfalco...
Let's discuss if that covers our needs and constraints.
Paul, thanks for the alternative proposal.
The request was:
Provide a easy way to pass a test into LAVA from an android-build configuration.
Yong Qin's approach seems reasonable because its of the form:
MY_DEFINE="runmycommand --paramone 1 --paramtwo 2"
I don't like Paul's proposal because if you need something that complicated you should just use the LAVA python interface. I just want something simple.
Something like:
LAVA_TEST_1="runmycommand --paramone 1 --paramtwo 2" LAVA_TEST_PARSE_1="some regex"
LAVA_TEST_2="runmyothercommand --paramone 1" LAVA_TEST_PARSE_2="some other regex"
..and that's it. LAVA would then run LAVA_TEST_1 and LAVA_TEST_2 etc... and use LAVA_TEST_PARSE_1 and LAVA_TEST_PARSE_2 to parse the results nad send them back to the android-build.
All the tests we run on Android will be baked into the build, so we don't have to worry about installing them.
I don't even want to have to do this:
LAVA_TESTS="LAVA_TEST_1 LAVA_TEST_2"
...because that's adding too much structure.
This is really just a way to get a test in without needing to add a bunch of python code to LAVA. The flat list of commands is easy to see, and there's no tree structure to contend with. If you need more structure you'd write some python or write the structure into a script.
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android