[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 15:54, Anthony PERARD wrote: > On Thu, Oct 21, 2021 at 01:24:27PM +0200, Jan Beulich wrote: >> 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: >>>>>>> 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. > > So, there isn't really anything to do with the timestamps :-). I guess > we could keep using symbolic links, but force update the link at every > build. > > I've tried that: > $(obj)/%.c: $(abs_srctree)/common/efi/%.c FORCE > $(Q)ln -nsf $< $@ > > and make seems happy. The link command run every time (due to adding > FORCE), but the `CC` command isn't, so that seems good. The recipe that > would run the `CC` command check if the prerequisite are newer than the > target using $? so it doesn't matter if the rule that update the source > file as run or not. Looks okay to me. One additional consideration, though: Linux puts a "source" link in the build tree. If we did so as well, then that could be the only absolute symlink that's needed. Links like the one you suggest could be relative ones into source/. But I guess this could as well be left as a future exercise, in case anyone cares to limit the number of absolute symlinks. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |