Bring test_x86_emulator in line with other tests by adding
install/uninstall rules.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)
--
2.34.1On 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@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. ~Andrew
On Tue, May 20, 2025 at 10:02:05PM +0100, 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@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. I think we are fine with regards to cross compiling. It's probably broken. Sometime, XEN_COMPILE_ARCH is used as XEN_TARGET_ARCH. Also the makefile is executed only if the target is x86 (in the makefile in the parent directory). So if the target is not x86, nothing is install or built. But if the target is x86 and the host is !x86 then the build is probably going to fail. > The very real problem is that this doesn't run in x86 CI, because and > only because it doesn't have an install target. So, the patch seems fine to me: Acked-by: Anthony PERARD <anthony.perard@vates.tech> Thanks, -- Anthony PERARD
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@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. 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 ... Jan
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@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
On Tue, 20 May 2025, 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@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. This patch has been on the list of a while. I do think that having the x86 emulator better tested as part of the CI-loop is a priority so I am in favor of taking the patch as is -- anything to make progress in terms of running test_x86_emulator as part of the CI-loop. Acked-by: Stefano Stabellini <sstabellini@kernel.org> Cheers, Stefano
On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: > Bring test_x86_emulator in line with other tests by adding > install/uninstall rules. > > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)) > + FWIW, should you check that HOSTCC == CC before installing? Otherwise I'm unsure of the result in cross-compiled builds, as the x86_emulator is built with HOSTCC, not CC. Thanks, Roger.
On 16/05/2024 12:35, Roger Pau Monné wrote: > On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >> Bring test_x86_emulator in line with other tests by adding >> install/uninstall rules. >> >> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)) >> + > > FWIW, should you check that HOSTCC == CC before installing? Otherwise > I'm unsure of the result in cross-compiled builds, as the x86_emulator > is built with HOSTCC, not CC. > > Thanks, Roger. Right... More generally, should we do s/CC/HOSTCC/ on all compiler checks? I see no particular reason to do them on $(CC) rather than the actual compiler used during build. Cheers, Alejandro
On 16.05.2024 14:29, Alejandro Vallejo wrote: > On 16/05/2024 12:35, Roger Pau Monné wrote: >> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >>> Bring test_x86_emulator in line with other tests by adding >>> install/uninstall rules. >>> >>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)) >>> + >> >> FWIW, should you check that HOSTCC == CC before installing? Otherwise >> I'm unsure of the result in cross-compiled builds, as the x86_emulator >> is built with HOSTCC, not CC. >> >> Thanks, Roger. > > Right... > > More generally, should we do s/CC/HOSTCC/ on all compiler checks? I see > no particular reason to do them on $(CC) rather than the actual compiler > used during build. No. There really is a mix here, intentionally. Anything built through testcase.mk is using CC, and hence respective checking needs to use CC, too. That said, I don't think the split is done quite correctly just yet, which may raise the question of whether having the split is actually worth it. Jan
Hi, On 16/05/2024 13:37, Jan Beulich wrote: > On 16.05.2024 14:29, Alejandro Vallejo wrote: >> On 16/05/2024 12:35, Roger Pau Monné wrote: >>> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >>>> Bring test_x86_emulator in line with other tests by adding >>>> install/uninstall rules. >>>> >>>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)) >>>> + >>> >>> FWIW, should you check that HOSTCC == CC before installing? Otherwise >>> I'm unsure of the result in cross-compiled builds, as the x86_emulator >>> is built with HOSTCC, not CC. >>> >>> Thanks, Roger. >> >> Right... >> >> More generally, should we do s/CC/HOSTCC/ on all compiler checks? I see >> no particular reason to do them on $(CC) rather than the actual compiler >> used during build. > > No. There really is a mix here, intentionally. Anything built through testcase.mk > is using CC, and hence respective checking needs to use CC, too. That said, I > don't think the split is done quite correctly just yet, which may raise the > question of whether having the split is actually worth it. > > Jan I'm a bit puzzled by this. Why do we compile pieces of the test binary with different toolchains? At a glance it seems inconsequential in the native case and fully broken on the cross-compiled case (which I guess is what Roger was hinting at and I failed to notice). Why the distinction? What am I missing? Cheers, Alejandro
On 16.05.2024 16:46, Alejandro Vallejo wrote: > Hi, > > On 16/05/2024 13:37, Jan Beulich wrote: >> On 16.05.2024 14:29, Alejandro Vallejo wrote: >>> On 16/05/2024 12:35, Roger Pau Monné wrote: >>>> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >>>>> Bring test_x86_emulator in line with other tests by adding >>>>> install/uninstall rules. >>>>> >>>>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@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)) >>>>> + >>>> >>>> FWIW, should you check that HOSTCC == CC before installing? Otherwise >>>> I'm unsure of the result in cross-compiled builds, as the x86_emulator >>>> is built with HOSTCC, not CC. >>>> >>>> Thanks, Roger. >>> >>> Right... >>> >>> More generally, should we do s/CC/HOSTCC/ on all compiler checks? I see >>> no particular reason to do them on $(CC) rather than the actual compiler >>> used during build. >> >> No. There really is a mix here, intentionally. Anything built through testcase.mk >> is using CC, and hence respective checking needs to use CC, too. That said, I >> don't think the split is done quite correctly just yet, which may raise the >> question of whether having the split is actually worth it. > > I'm a bit puzzled by this. Why do we compile pieces of the test binary > with different toolchains? > > At a glance it seems inconsequential in the native case and > fully broken on the cross-compiled case (which I guess is what Roger was > hinting at and I failed to notice). > > Why the distinction? What am I missing? It's convoluted and not fully consistent, yes. Consider for a moment that the emulator truly was what its name says, i.e. not merely re-playing insns. In such a case it could be run on non-x86, while still emulating x86 code. Thus code being emulated and code doing the emulation would necessarily need to be built with different compilers. It being (in most cases) merely replaying, the boundary has been fuzzy for a very long time: While for most parts it's clear what group they fall into, test_x86_emulator.c itself is (has become? even 3.2.3 already has at least one instance) a hybrid. Yet in principle this file should also be buildable with the (x86 or non-x86) host compiler. Jan
On 16.05.2024 13:07, Alejandro Vallejo wrote: > Bring test_x86_emulator in line with other tests by adding > install/uninstall rules. > > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> I'd expect such a change to come with a word towards what use the binary has on the installed system. Imo we should not randomly put binaries in place when there's - afaict - absolutely no use for them outside of development. Jan > --- 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)
Hi, On 16/05/2024 12:16, Jan Beulich wrote: > On 16.05.2024 13:07, Alejandro Vallejo wrote: >> Bring test_x86_emulator in line with other tests by adding >> install/uninstall rules. >> >> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> > > I'd expect such a change to come with a word towards what use the binary has > on the installed system. First of all, having some tests installed and some not is highly confusing (See [1]). > Imo we should not randomly put binaries in place > when there's - afaict - absolutely no use for them outside of development I don't disagree, but that's (imo) a packaging matter. For reference XenServer has a xen-dom0-tests package for this very purpose, so we can install it or withhold it at will. Being able to validate that the development invariants still hold on whatever machine you happen to be running on is generally a good thing, I reckon. Cheers, Alejandro ============================== [1] (grepped for the install target in the tests folder) [snip] -- ./paging-mempool/Makefile:install: all ./paging-mempool/Makefile- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) ./paging-mempool/Makefile- $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN) -- ./xenstore/Makefile:install: all ./xenstore/Makefile- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) ./xenstore/Makefile- $(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN)) -- ./depriv/Makefile:install: all ./depriv/Makefile- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) ./depriv/Makefile- $(INSTALL_PROG) $(INSTALL_PRIVBIN) $(DESTDIR)$(LIBEXEC_BIN) -- ./cpu-policy/Makefile:install: all ./cpu-policy/Makefile- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) ./cpu-policy/Makefile- $(if $(TARGETS),$(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC_BIN)) [snip]
© 2016 - 2026 Red Hat, Inc.