On 21/05/2025 8:06 am, Jan Beulich wrote: > On 20.05.2025 23:02, Andrew Cooper wrote: >> On 16/05/2024 12:07 pm, Alejandro Vallejo wrote: >>> Bring test_x86_emulator in line with other tests by adding >>> install/uninstall rules. >>> >>> Signed-off-by: Alejandro Vallejo <alejandro.vall...@cloud.com> >>> --- >>> tools/tests/x86_emulator/Makefile | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/tools/tests/x86_emulator/Makefile >>> b/tools/tests/x86_emulator/Makefile >>> index 834b2112e7fe..30edf7e0185d 100644 >>> --- a/tools/tests/x86_emulator/Makefile >>> +++ b/tools/tests/x86_emulator/Makefile >>> @@ -269,8 +269,15 @@ clean: >>> .PHONY: distclean >>> distclean: clean >>> >>> -.PHONY: install uninstall >>> -install uninstall: >>> +.PHONY: install >>> +install: all >>> + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) >>> + $(if $(TARGET-y),$(INSTALL_PROG) $(TARGET-y) $(DESTDIR)$(LIBEXEC_BIN)) >>> + >>> +.PHONY: uninstall >>> +uninstall: >>> + $(RM) -- $(addprefix $(DESTDIR)$(LIBEXEC_BIN)/,$(TARGET-y)) >>> + >>> >>> .PHONY: run32 clean32 >>> ifeq ($(XEN_COMPILE_ARCH),x86_64) >> [starting a clean thread] >> >> x86_emulator is not special enough to behave differently to the rest of >> tools/. >> >> Theoretical concerns over cross compiling test_x86_emulator for non-x86 >> can be fixed by whomever first wants to do this. >> >> The very real problem is that this doesn't run in x86 CI, because and >> only because it doesn't have an install target. > Well, I won't insist on any of the adjustments to be made that previously > were discussed, yet I wonder: Elsewhere you complain (at times loudly) > about (building up) technical debt.
Yes I do complain about technical debt a lot. Technical debt is having a test and not running it. > > Further, without the compiler overridden to be the absolutely newest one > available, coverage of such testing would be limited (especially if some > of my work there would finally, in part after years, be unblocked). Yes, > that's better than nothing, but still ... Still what? We literally have nothing, and this gets us something, without interfering with anyone's pre-existing workflow. Alpine Linux (the base of our GitlabCI testing) is prompt at keeping it's GCC up to date. (We're less prompt at staying on up-to-date versions of Alpine, but that's on the todo list.) ~Andrew
