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