[qmtest] PATCH: RemoteHost support
Mark Mitchell
mark at codesourcery.com
Mon Jun 13 16:58:26 UTC 2005
Stefan Seefeld wrote:
> Mark,
>
> this patch looks great ! Just some minor questions:
>
> Mark Mitchell wrote:
>
>> This patch adds a new abstraction (called RemoteHost) that can be used
>> for running programs remotely. (This facility is in contrast to the
>> QMTest "Target" abstraction, which allows you to run *tests* remotely;
>> this facility allows a test running on one machine to run a program on
>> another.)
>
>
> Why don't you call the extension 'Host' and make 'RemoteHost' and
> 'LocalHost'
> subclasses ? I understand that the whole point of the abstraction is to
> enable remote execution, it just sounds funny to define 'LocalHost' as
> a subclass of 'RemoveHost'.
Yes, I was being a little bit cute. But, I really did want to emphasize
the "remote" aspect of the class; things like "UploadFile" don't
generally make sense with a local host; it just happens that we treat
local hosts as a special case of remote ones. I also thought that
"Host" would be more likely to conflict with other classes; maybe, for
example, people have "Host" classes that have methods like "GetIPAddr".
I don't feel very strongly, though; if you think "Host" is better, I'll
change it. What do you think?
>> ! The 'CompilerTable' resource provides the following context
>> ! variables to all tests that depend upon the resource:
>> ! ! - 'CompilerTable.compilers'
>> ! ! The 'compilers' variable is a map from language names to
>> ! instances of 'Compiler'. Test classes should obtain the
>> ! 'Compiler' to use when compiling source files by using this
>> ! map.
>
>
> It seems the names defined for 'CompilerTable.languages' are just
> conventions that user code (i.e. specific test / resource classes)
> need to know about. However, wouldn't it be good to standardize
> at least the names for the most common languages ?
> In my first encounter with the CompilerTable it wasn't obvious
> to me whether C++ would be spelled 'cplusplus', 'cxx', or something
> else.
>
> CompilerTable previously defined 'CompilerTable.compiler_table', instead
> of 'CompilerTable.compilers'. While I think the new name is clearer,
> I'm wondering whether any code still expects 'compiler_table', i.e.
> whether the above change breaks backward compatibility. If not, all the
> better.
We can get away with this change. The only user of the CompilerTable
stuff is the CodeSourcery C++ ABI Testsuite, which has its own version
of CompilerTest (at present), and will (soon) be adjusted to the use the
new version in QMTest. So, there are no users of the old spelling,
except for possible users of QMTest CVS in the last few weeks.
--
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com
(916) 791-8304
More information about the qmtest
mailing list