[PATCH 2/3] testsuite: User input define added

Chris Johns chrisj at rtems.org
Tue Mar 31 22:06:09 UTC 2020


On 2020-03-31 21:02, Sebastian Huber wrote:
> On 31/03/2020 11:56, Chris Johns wrote:
> 
>> On 2020-03-31 19:57, Moyano, Gabriel wrote:
>>> diff --git a/testsuite/arphole/test_main.c 
>>> b/testsuite/arphole/test_main.c
>>> index 19d67b89..45a28cc0 100644
>>> --- a/testsuite/arphole/test_main.c
>>> +++ b/testsuite/arphole/test_main.c
>>> @@ -54,6 +54,7 @@
>>>   #include <rtems/bsd/util.h>
>>>     #define TEST_NAME "LIBBSD ARP HOLE"
>>> +#define TEST_STATE_USER_INPUT 1
>>
>> In rtems.git these test states are defined on the compiler command 
>> line. The user input state is OK to define in the code but it gets 
>> more difficult with the others to manage them in the code and so I am 
>> wondering how we manage the other states in libbsd? And if we manage 
>> those in the build system then why manage this one? 
> 
> Why should this define move to the build system of libbsd. It is a 
> property of the test if it is interactive or not.

I was only highlighting the inconsistencies and problems that result. 
Placing the define in the source of a test was consider in rtems.git 
however having all data related to controlling tests in a single place 
was considered the better path. I asset this is still valid.

> In RTEMS we have it in the build system since you can set tests to 
> expected fail or disable them per BSP. I am not sure if we need this 
> extra complexity for libbsd right now.

The progression of this statement is needing to make sure all tests 
never fail on libbsd on all platforms. I do not think this is 
reasonable. I am left wondering how many people run these tests and on 
which platforms? I have no seen any posts to builds at ..

> We could at some point in time 
> use the same build system for RTEMS and libbsd.

This is a different discussion. I am not yet conformable with the SPEC 
path enough to say it is OK for all parts of the project. We need to see 
it used in specific and critical places first and then evaluate the 
effect it has.

Chris


More information about the devel mailing list