[PATCH] build: Add RTEMS_QUALIFIED

Chris Johns chrisj at rtems.org
Sun Nov 5 23:39:36 UTC 2023


On 3/11/2023 7:58 pm, Sebastian Huber wrote:
> diff --git a/cpukit/libtest/testbeginend.c b/cpukit/libtest/testbeginend.c
> index d520a45e62..45fd1343fa 100644
> --- a/cpukit/libtest/testbeginend.c
> +++ b/cpukit/libtest/testbeginend.c
> @@ -41,9 +41,15 @@
>  #endif
>  
>  #include <rtems/test-info.h>
> -#include <rtems/test-printer.h>
>  #include <rtems/version.h>
>  
> +#if defined(RTEMS_QUALIFIED)
> +#include <rtems/bspIo.h>
> +#include <rtems/dev/io.h>
> +#else
> +#include <rtems/test-printer.h>
> +#endif
> +
>  static const char* const test_state_strings[] =
>  {
>    "EXPECTED_PASS",
> @@ -55,8 +61,14 @@ static const char* const test_state_strings[] =
>  
>  int rtems_test_begin(const char* name, const RTEMS_TEST_STATE state)
>  {
> +#if defined(RTEMS_QUALIFIED)
> +  return _IO_Printf(
> +    rtems_put_char,
> +    NULL,
> +#else
>    return rtems_printf(
>      &rtems_test_printer,
> +#endif

I feel this change and approach needs more discussion publicly before we
determine the path the project follows. I would like to hear from Joel and Gedare?

As things stand ...

$ grep -r RTEMS_QUALIFIED .
$

This patch is introducing a new and rather broad category for a single define to
cover. Is the role and bounds of this define documented?

The define is past tense so it implies to me you need to have the code it covers
qualified somewhere before it can be merged? Is there a qualified build of RTEMS
publicly available I can download to compare?

In relation to the build system changes who decided which files are included and
which are not? What if one profile wants a file included and another does not?

Chris



More information about the devel mailing list