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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel