On 19/10/18 5:47 pm, Sebastian Huber wrote:
> ----- Am 18. Okt 2018 um 19:56 schrieb Chris Johns chr...@rtems.org:
>
>> On 18/10/18 6:38 pm, Sebastian Huber wrote:
>>> Use a test body with a proper RTEMS application configuration to avoid a
>>> dependency on the default configuration. Do not include
>>> <rtems/score/cpuopts.h> directly since this header file is an
>>> implementation detail.
>>>
>>> Update #3551.
>>> ---
>>> rtems.py | 30 +++++++++++++++++-------------
>>> 1 file changed, 17 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/rtems.py b/rtems.py
>>> index 1b0da60..c7a1966 100644
>>> --- a/rtems.py
>>> +++ b/rtems.py
>>> @@ -259,13 +259,18 @@ def configure(conf, bsp_configure = None):
>>> #
>>> # Checks for various RTEMS features.
>>> #
>>> - conf.multicheck({ 'header_name': 'rtems/score/cpuopts.h'},
>>> - msg = 'Checking for RTEMS CPU options header',
>>> - mandatory = True)
>>> - load_cpuopts(conf, ab, rtems_path)
>>
>> OK.
>>
>>> - conf.multicheck({ 'header_name': 'rtems.h'},
>>> - msg = 'Checking for RTEMS header',
>>> - mandatory = True)
>>
>> Why remove the test? I see the app test below checks for the header however
>> the
>> test creates a nice specific error message.
>
> The test is not a simple compile test and dosen't only check that you can
> include <rtems.h>. In addition it checks that you can link a sample
> application successfully.
The test you have added is a good addition. I am asking, why not keep both
tests? It comes down to the error message and how user friendly it is. If
'rtems.h' is present we can assume it is an installed RTEMS. The second test can
check the quality of the install. I would like to avoid users needing to dig
into a config log to find an error and then try to understand it to figure out
they have a bad path on the command line.
What is the error report with just the 'main' test you added and an invalid
RTEMS path?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
