kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> 
> 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.