Re: [Xen-devel] [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.06.16 at 16:20, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 06/06/2016 07:04 AM, Jan Beulich wrote:
>>
>>> --- a/tools/firmware/hvmloader/Makefile
>>> +++ b/tools/firmware/hvmloader/Makefile
>>> @@ -20,8 +20,6 @@
>>>  XEN_ROOT = $(CURDIR)/../../..
>>>  include $(XEN_ROOT)/tools/firmware/Rules.mk
>>>  
>>> -SUBDIRS := acpi
>>> -
>>>  # The HVM loader is started in 32-bit mode at the address below:
>>>  LOADADDR = 0x100000
>>>  
>>> @@ -33,10 +31,18 @@ CFLAGS += $(CFLAGS_xeninclude)
>>>  # We mustn't use tools-only public interfaces.
>>>  CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
>>>  
>>> +# ACPI table builder
>>> +ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
>>> +vpath %.c $(ACPI_PATH)
>> Please don't - this would preclude having files with the same names
>> in hvmloader/ and (the future) libacpi/.
>>
>>> @@ -95,7 +101,11 @@ all: subdirs-all
>>>  ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
>>>  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>>>  
>>> -hvmloader: $(OBJS) acpi/acpi.a
>>> +.NOTPARALLEL: $(ACPI_SRC)
>> And very clearly we will want to avoid the use of .NOTPARALLEL
>> anywhere in our trees.
>>
>>> +$(ACPI_SRC):
>>> +   $(MAKE) -C $(ACPI_PATH)
>> The more that you can't do this from multiple points in the tree. Did
>> you consider e.g. symlinking the subtree into the multiple parent
>> trees?
> 
> How would this help with avoiding building the intermediate files from
> multiple paces (libxc and hvmloader specifically --- that was the reason
> for .NOTPARALLEL).

If you symlink the source files into three different subdirectories,
building in those three subdirectories will become independent. (Or,
just like libelf, build the hypervisor part in the actual directory, and
symlink only the libxc and hvmloader uses.)

> I thought of flock-ing directory but then I was afraid that interrupted
> make may not clean up properly.
> 
> Or are you suggesting symlinking to help with include paths (i.e. to
> drop vpath above)?

That as well - symlinking would solve a number of issues that I have
pointed out, afaict at least.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel