Hi Heinrich, On Thu, 18 Feb 2021 at 22:08, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > On 2/19/21 5:52 AM, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 17 Feb 2021 at 04:58, Heinrich Schuchardt <xypron.g...@gmx.de> > > wrote: > >> > >> test/cmd/setexpr.c cannot be linked with CONFIG_CMD_SETEXPR=n: > >> > >> ld.bfd: test/built-in.o: in function `setexpr_test_sub': > >> test/cmd/setexpr.c:227: undefined reference to `setexpr_regex_sub' > >> ld.bfd: test/built-in.o: in function `setexpr_test_backref': > >> test/cmd/setexpr.c:267: undefined reference to `setexpr_regex_sub' > >> > >> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> > >> --- > >> test/cmd/Makefile | 2 +- > >> test/cmd_ut.c | 2 ++ > >> 2 files changed, 3 insertions(+), 1 deletion(-) > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > But I wonder what the goal is here. There is an assumption at present > > that sandbox runs these tests and has the required features enabled. > > What are you trying to do? > > > > CONFIG_UNIT_TEST does not depend on the architecture. > > I enable and run unit tests on my real hardware, e.g. under RISC-V. > Tests that cannot be built or run with the current configuration should > not lead to build failures.
If you want to support this we probably have quite a few things to fix up. It might be worth doing it all at once and documenting what sort of tests are permitted on real hardware. For example, some tests rely on the test .dts and resetting DM which probably won't go down well on real hardware. Are you just thinking about the cmd tests for now? What sort of bugs are you trying to find? Regards, Simon
