Pre-processor magic or test library?

[Chris Johns]

On 03/11/2017 00:22, Sebastian Huber wrote:
> On 02/11/17 13:01, Sebastian Huber wrote:
>> On 30/10/17 21:56, Chris Johns wrote:
>>> On 31/10/2017 01:21, Joel Sherrill wrote:
>>>> On Oct 30, 2017 8:43 AM, "Chris Johns" <chrisj at rtems.org
>>>> <mailto:chrisj at rtems.org>> wrote:
>>>>      On 28/10/2017 22:42, Sebastian Huber wrote:
>>>>      > we have currently some pre-processor magic to map the standard output
>>>>      functions to the RTEMS test printer. This works only if you include
>>>>      <tmacros.h> in every test file in the right spot. An alternative would
>>>> be to
>>>>      use a separate library for all tests, e.g. librtemstest.a which provides
>>>>      puts(), printf(), fprintf(), etc. How do you think about this?
>>>>
>>>>      I like it.
>>>>
>>>> I like the idea but not using the same names for the.methods. this will mean
>>>> that if the linker magic isn't right, you end up getting the wrong
>>>> implementation
>>>>
>>> The testing output routings could postfix a character like '|' to '\n' and the
>>> tester can check the output always have that character in column 1 and flag the
>>> test and incorrectly linked if it does not?
>>
>> Using the wrong output facility is not a catastrophe. Most tests work fine
>> with an interrupt driven console driver. I tried to provide a special console
>> driver using the polled char input/output functions (attached patch), however,
>> most console drivers define console_initialize() and the BSP_output_char in
>> one file. Changing this would require more work than I can dedicate to this task.
> 
> The pre-processor magic in the testsuite doesn't catch the various places in
> RTEMS which directly use fprintf(), etc. for example
> rtems_capture_print_timestamp().

Yes, we would need to use a linker trick or head down one of the paths you have
posted. Please decide on the path you think is best with your limited time.

> A quick hack to enable a console driver in librtemsio.a would be to define
> console_*() as weak functions in the normal console driver. Separating the
> console driver from the device-specifics would be several days of work. I guess
> nobody has a time budget for this.

I am the same.

> Is this stuff really important for the next RTEMS release?

It is not important we get this is perfect. It was important to get consistent
results across for testing on hardware so the tier structure could finally be
implemented and made available and I feel we have done that. There are some
minor things still being shaken out, for example your fprintf changes which is fine.

I am working on documentation for Testing for the User manual which is getting
close and then I have one more for thing to implement, a sister command to
`rtems-test` called `rtems-run` which uses the testing framework but runs a
single executable outputting to stdout the console output.

Chris