[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v7 42/51] build: grab common EFI source files in arch specific dir
On 21.10.2021 13:03, Anthony PERARD wrote: > On Mon, Oct 18, 2021 at 10:48:26AM +0200, Jan Beulich wrote: >> On 15.10.2021 18:29, Anthony PERARD wrote: >>> On Thu, Oct 14, 2021 at 10:51:44AM +0200, Jan Beulich wrote: >>>> On 24.08.2021 12:50, Anthony PERARD wrote: >>>>> --- a/xen/arch/arm/efi/Makefile >>>>> +++ b/xen/arch/arm/efi/Makefile >>>>> @@ -1,4 +1,10 @@ >>>>> CFLAGS-y += -fshort-wchar >>>>> +CFLAGS-y += -I$(srctree)/common/efi >>>> >>>> Perhaps another opportunity for -iquote? >>> >>> Yes. >>> >>>>> obj-y += boot.init.o pe.init.o ebmalloc.o runtime.o >>>>> obj-$(CONFIG_ACPI) += efi-dom0.init.o >>>>> + >>>>> +$(obj)/%.c: common/efi/%.c >>>>> + $(Q)cp -f $< $@ >>>> >>>> In case both trees are on the same file system, trying to hardlink first >>>> would seem desirable. When copying, I think you should also pass -p. >>> >>> I don't know if doing an hardlink is a good thing to do, I'm not sure of >>> the kind of issue this could bring. As for -p, I don't think it's a good >>> idea to copy the mode, ownership, and timestamps of the source file, I'd >>> rather have the timestamps that Make expect, e.i. "now". >> >> Why would "now" be correct (or expected) in any way? The cloned file is no >> different from the original. Nevertheless I agree that -p is not ideal; >> it's just that the more fine grained option to preserve just the timestamp >> is non-standard afaik. You could try that first and fall back to -p ... >> Otherwise, failing hard linking and using "cp -p", I'm afraid I'd prefer >> symlinking despite the arguments against it that you name in the >> description. > > I guess I'm missing something, is there a reason to keep/copy the > timestamps of the original files? Avoidance of confusion is my main aim here. I certainly would be puzzled to see what looks like a source file to have a time stamp much newer than expected. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |