>
> We could address a) and b) by having a single DLL/DSO specific entrypoint for
> all tests,
> with a big switch in there to route to the actual test. This scaffolding has
> some
> maintenance cost, and begins to wash out the ease of using python on top, but
> perhaps not
> fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C string is
like a
printf format string.
So it would be possible to make this callable from python and pass all required
arguments
for any worker function. You would have to instantiate the C++ instance before
calling
any member function which is your worker function. But that could be done in
the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum, formatStringTellingArgumentTypesInTuple,
Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments
in tuple.
result = obj->WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
}
}
return test_result( result ) ; // telling what just happened.
}
The above could be a seed for better ideas. It is a means of testing any
"worker
function" from python.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
