Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.vallejo@xxxxxxxxx>
>>> ---
>>>  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