On 04/29/2015 19:35, Christophe Milard wrote:
It looks that Stuart and I now agree on what we hope would be an
improvment of the test environment.
I guess you (Maxim, Mike, Anders) have been following the
conversation, but here comes some summary.
I lost on some point. Sorry. But after porting dpdk I think than more
separate small simple test binaries we have then better.
Will go thought this email e little bit later with fresh head.
Maxim.
Does this looks reasonable for you as well?
Christophe.
1) validation would contain 1 directory per module + common.
Each <module> directory would contain all the C files defining all the
module tests, the main files (one per executable), and a Makefile.am.
This Makefile.am would build (but not run):
-lib<module>.a: a lib containing all test for this module.
-<module>_*: the executable(s) to run the test. (usually one)
In most of the cases lib<module>.a would be build from a single C
file. And the unique executable, called <module>, would be built from
compiling <module>_main.c and linking with lib<module>.a and common
things.
But some module may have many C files to define the tests (crypto,
init,... probably many more in the future)... and many executable (and
main)
For init the validation/odp_init directory would contain:
-init_ok.c
-init_abort.c
-init_log.c
-init_abort_main.c
-init_log_main.c
-init_ok_main.c
-Makefile.am which would build (but not run):
The following files would be created on build:
-libinit.a (containing all test from init_ok.c, init_log.c, init_abort.c)
-init_abort, init_ok, and init_log. the 3 executable to run the tests,
built fromtheir respective main, libinit.a and common.
Executables (mains) would just be a call to run_main (or whatever you
want to call it), with a suite as parameter. run_main would be part of
a Lib (in built in validation/common) which would define run_main and
the 4 weak functions (tests_global_init/term and platform_init/term).
This lib would be given last in the <executable>_LDADD Makefile.am
variable, making sure (hoppefully) that the weak get overloaded by
"strongs" when needed.
The validation/common would contain the lib containing run_main + the
weak versions of global_init/term (doing odp_init/term as default) and
the platform_init/term (doing nothing as default)
The common validation/Makefile.am would list all the executables to be
run as part of tests
What I like in this approach is that:
- everything belonging to one module is located under the module
directory.
- Modules can have many test executable (as init), clearly gathered in
the module directory
- A superlib containing all tests can easily be done by linking all
the lib<module>.a together
- Makefile for each module are separated: less merge burden if two
persons are adding tests in 2 different modules. (just the addition of
a new executable or new API module would affect the validation/Makefile.am
- The structure is there to start with. No-one will be tempted to add
a test directly under validation if the <module> directory is already
there.
- Platform tests need to be added only if platform specific stuff is
needed.
- Tests are listed an run from validation, so we still get the
grand-total we are used to.
The drawback:
- Platforms will only have 2 hook (before and after the all tests of a
module): It seems you alreaady agree on that :-). In the future a
function to disable some tests can be added to give the platform a
chance to skip a test.
- The grand total one we get when running the tests will not match the
number of modules, but the number of test executables instead. (as today)
- This "hook" approaches diverges a bit from an homogeneous CUNIT
approach. If we do build this "superlib" containing all tests, its
usage will be hard, unless we can integrate some of these hooks into
CUNIT (future improvement?)
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
