*.tcfg specification?

[Sebastian Huber]

Hello,

what is the purpose of the *.tcfg test configuration files? You can 
disable compilation of test programs with them, e.g.

exclude: flashdisk01

The "testsuites/rtems-test-check.py" contains a bit more stuff. What is 
really needed? I have to map this to the new build system.

One approach is to use the "enabled-by" attribute to disable test 
programs on demand, e.g.:

$ cat spec/build/testsuites/samples/RTEMS-BUILD-TEST-SAMPLE-TICKER.yml
active: true
build-type: test-program
cflags: []
cppflags: []
cxxflags: []
derived: false
enabled-by:
- not: DISABLE_TEST_SAMPLE_TICKER
features: c cprogram
header: ''
includes: []
level: 1.15
links: []
normative: true
order: 0
ref: ''
reviewed: null
source:
- testsuites/samples/ticker/init.c
- testsuites/samples/ticker/tasks.c
stlib: []
target: testsuites/samples/ticker.exe
text: ''
type: build
use: []

A BSP can use a "build-type: option" file to disable tests, e.g.

actions:
- disable-tests:
   - SAMPLE/TICKER
   - LIB/FLASHDISK01

An open issue is how and if we should set other states, e.g. expected to 
fail. We could generate a "bsp/teststate.h" file for each BSP which 
optionally defines for each test a state other than "pass", e.g.

#define TEST_SAMPLE_TICKER_STATE RTEMS_TEST_STATE_FAIL

This could be also realized with a special option action:

actions:
- set-test-states:
   - SAMPLE/TICKER: disable
   - LIB/FLASHDISK01: xfail

The "set-test-states" action can validate if the state exists. I can use 
the "enable-by" for "disable" states and the "bsp/teststate.h" file for 
other states.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.