| Message ID | bd68e8f4-ce57-7798-f6d2-53e85319b8d4@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | libxl: fix libacpi dependency | expand |
On 27.10.2020 12:40, Jan Beulich wrote: > $(DSDT_FILES-y) depends on the recursive make to have run in libacpi/ > such that the file(s) itself/themselves were generated before > compilation gets attempted. The same, however, is also necessary for > generated headers, before source files including them would get > attempted to be compiled. > > The dependency specified in libacpi's Makefile, otoh, is entirely > pointless nowadays - no compilation happens there anymore (except for > tools involved in building the generated files). Together with it, the > rule generating acpi.a also can go away. > > Reported-by: Olaf Hering <olaf@aepfle.de> > Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests") > Signed-off-by: Jan Beulich <jbeulich@suse.com> I'd appreciate a libxl side ack (or otherwise) here. Thanks, Jan > --- > Arguably we might also use $(ACPI_OBJS) instead of specifying just the > one object file we know has respective #include directives. > > --- a/tools/libacpi/Makefile > +++ b/tools/libacpi/Makefile > @@ -89,11 +89,6 @@ iasl: > @echo > @exit 1 > > -build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h ssdt_laptop_slate.h > - > -acpi.a: $(OBJS) > - $(AR) rc $@ $(OBJS) > - > clean: > rm -f $(C_SRC) $(H_SRC) $(MK_DSDT) $(C_SRC:=.$(TMP_SUFFIX)) > rm -f $(patsubst %.c,%.hex,$(C_SRC)) $(patsubst %.c,%.aml,$(C_SRC)) $(patsubst %.c,%.asl,$(C_SRC)) > --- a/tools/libs/light/Makefile > +++ b/tools/libs/light/Makefile > @@ -32,7 +32,7 @@ ACPI_PATH = $(XEN_ROOT)/tools/libacpi > DSDT_FILES-$(CONFIG_X86) = dsdt_pvh.c > ACPI_OBJS = $(patsubst %.c,%.o,$(DSDT_FILES-y)) build.o static_tables.o > ACPI_PIC_OBJS = $(patsubst %.o,%.opic,$(ACPI_OBJS)) > -$(DSDT_FILES-y): acpi > +$(DSDT_FILES-y) build.o: acpi > vpath build.c $(ACPI_PATH)/ > vpath static_tables.c $(ACPI_PATH)/ > >
On Thu, Nov 05, 2020 at 12:56:46PM +0100, Jan Beulich wrote: > On 27.10.2020 12:40, Jan Beulich wrote: > > $(DSDT_FILES-y) depends on the recursive make to have run in libacpi/ > > such that the file(s) itself/themselves were generated before > > compilation gets attempted. The same, however, is also necessary for > > generated headers, before source files including them would get > > attempted to be compiled. > > > > The dependency specified in libacpi's Makefile, otoh, is entirely > > pointless nowadays - no compilation happens there anymore (except for > > tools involved in building the generated files). Together with it, the > > rule generating acpi.a also can go away. > > > > Reported-by: Olaf Hering <olaf@aepfle.de> > > Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests") > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > I'd appreciate a libxl side ack (or otherwise) here. Acked-by: Wei Liu <wl@xen.org> Feel free to commit this yourself.
--- a/tools/libacpi/Makefile +++ b/tools/libacpi/Makefile @@ -89,11 +89,6 @@ iasl: @echo @exit 1 -build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h ssdt_laptop_slate.h - -acpi.a: $(OBJS) - $(AR) rc $@ $(OBJS) - clean: rm -f $(C_SRC) $(H_SRC) $(MK_DSDT) $(C_SRC:=.$(TMP_SUFFIX)) rm -f $(patsubst %.c,%.hex,$(C_SRC)) $(patsubst %.c,%.aml,$(C_SRC)) $(patsubst %.c,%.asl,$(C_SRC)) --- a/tools/libs/light/Makefile +++ b/tools/libs/light/Makefile @@ -32,7 +32,7 @@ ACPI_PATH = $(XEN_ROOT)/tools/libacpi DSDT_FILES-$(CONFIG_X86) = dsdt_pvh.c ACPI_OBJS = $(patsubst %.c,%.o,$(DSDT_FILES-y)) build.o static_tables.o ACPI_PIC_OBJS = $(patsubst %.o,%.opic,$(ACPI_OBJS)) -$(DSDT_FILES-y): acpi +$(DSDT_FILES-y) build.o: acpi vpath build.c $(ACPI_PATH)/ vpath static_tables.c $(ACPI_PATH)/
$(DSDT_FILES-y) depends on the recursive make to have run in libacpi/ such that the file(s) itself/themselves were generated before compilation gets attempted. The same, however, is also necessary for generated headers, before source files including them would get attempted to be compiled. The dependency specified in libacpi's Makefile, otoh, is entirely pointless nowadays - no compilation happens there anymore (except for tools involved in building the generated files). Together with it, the rule generating acpi.a also can go away. Reported-by: Olaf Hering <olaf@aepfle.de> Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests") Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Arguably we might also use $(ACPI_OBJS) instead of specifying just the one object file we know has respective #include directives.