On Tue, 2016-01-12 at 14:18 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH RFC OSSTEST v1 05/12] make-*flight: Abolish
> $defsuite and $guestdefsuite"):
> > Instead have mfi-common set $suite or $guestsuite if it is unset. When
> > doing so move the use of local to this point, using local at the top
> > of the function would shadow any attempt to set a global value, while
> > restricting it only to when setting the default means it doesn't leak.
> > NB "local" scopes the variable to the containing function, not the
> > scope of the block where it is written (i.e. the if body in this
> > case).
>
> I'm not really sure this approach is right.
>
> If we were to decide that some of the tests resulting from
> test_matrix_iterate ought to have different suite values, we would
> have to (re)introduce a layer of indirection.
>
> Perhaps it would be better to retain defsuite and defguestsuite;
> move the copy from those to suite and guestsuite closer to use site;
> and unconditionally set the runvar ?
Actually, I think only this one hunk is the useful bit, corresponding to
the last line:
@@ -431,10 +434,10 @@ test_matrix_iterate () {
arch_runvars=\"\$ARCH_RUNVARS_$dom0arch\"
"
- debian_runvars="debian_kernkind=$kernkind debian_arch=$dom0arch"
- if [ $guestsuite != $defguestsuite ] ; then
- debian_runvars="$debian_runvars debian_suite=$guestsuite"
- fi
+ debian_runvars="debian_kernkind=$kernkind \
+ debian_arch=$dom0arch \
+ debian_suite=$guestsuite \
+ "
most_hostflags="arch-$dom0arch,arch-xen-$xenarch,suite-$suite,purpose-test"
if [ "x$min_linux_hostflag" != "x" ] ; then
I'm not sure about moving the copy from $deffoo to $foo from where it is
without this patch, they are already quite close to the use site I think.
WRT tests resulting from test-matrix_iterate having different $suite values
I think it is sufficient that the foo=$defoo is in the body of hte loop and
not outside.
I'll respin with just that one hunk.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
