Dne 3.4.2017 v 22:20 Sam Ravnborg napsal(a): > On Mon, Apr 03, 2017 at 03:25:10PM +0200, Michal Marek wrote: >> On 2017-04-03 09:42, Masahiro Yamada wrote: >>> Each Makefile knows it wants to see >>> additional headers in the source tree, or objtree. >>> >>> I am guessing the right approach in a long run is, >>> we require -I to specify $(srctree) or $(objtree) explicitly. >>> >>> ccflags-y := -I$(srctree)/foo/bar/baz >>> >>> or >>> >>> ccflags-y := -I$(objtree)/foo/bar/baz >>> >>> >>> (For the latter, we can omit $(objtree)/ as it is ./) >>> >>> >>> Then, delete $(call flags,_c_flags) after the conversion. >> >> Agreed. The addtree function is more of a hack to make things just work >> with O=, but AFAIK there is no clean way to implement VPATH for -I >> arguments. So it's sensible to get rid of the hack. It looks like it's >> going to be lot of work though: >> >> $ git grep -e '-I' -- '*Makefile*' | wc -l >> 732 >> $ git grep -e '-I *\$(\(src\|obj\)tree)' -- '*Makefile*' | wc -l >> 166 > > There was a goal long time ago that moving the kernel source should > not trigger a rebuild. > Any hardcoded path would violate this (like $(srctree), $(objtree)) > > I dunno if this is really something to aim for today. > > I have personally from time to time renamed the directory where > I have kernel soruce (which is seen like moving the kernel source), > and would not be happy if this always triggered a full rebuild. > But this is frankly a corner case. This should be working nowadays if you build without O= or if the buildtree points to a subdirectory of the source tree. The srctree variable is set to . or .. in such case. Although when I tried it now, it still does not look perfect: $ cd /dev/shm/mmarek/linux-2.6 $ make O=build -s defconfig $ make O=build -s -j64 Setup is 15500 bytes (padded to 15872 bytes). System is 6530 kB CRC 4bc8f6e2 Kernel: arch/x86/boot/bzImage is ready (#1) $ grep -r $PWD build/ Binary file build/arch/x86/boot/setup.elf matches Binary file build/arch/x86/boot/header.o matches Binary file build/arch/x86/boot/video.o matches Binary file build/arch/x86/boot/cpu.o matches Binary file build/arch/x86/boot/printf.o matches Binary file build/arch/x86/boot/string.o matches Binary file build/arch/x86/boot/video-mode.o matches Binary file build/arch/x86/boot/video-vga.o matches Binary file build/arch/x86/boot/early_serial_console.o matches Binary file build/arch/x86/boot/video-vesa.o matches Binary file build/arch/x86/boot/cpucheck.o matches Binary file build/arch/x86/boot/video-bios.o matches Binary file build/arch/x86/boot/tty.o matches Binary file build/arch/x86/boot/memory.o matches Binary file build/arch/x86/boot/pm.o matches Binary file build/arch/x86/boot/cmdline.o matches Binary file build/arch/x86/boot/main.o matches Binary file build/arch/x86/boot/a20.o matches Binary file build/arch/x86/boot/regs.o matches Binary file build/arch/x86/boot/version.o matches Binary file build/arch/x86/boot/edd.o matches Binary file build/arch/x86/boot/cpuflags.o matches Binary file build/arch/x86/boot/pmjump.o matches Binary file build/arch/x86/boot/copy.o matches Binary file build/arch/x86/boot/bioscall.o matches Binary file build/arch/x86/realmode/rm/video-bios.o matches Binary file build/arch/x86/realmode/rm/video-mode.o matches Binary file build/arch/x86/realmode/rm/video-vga.o matches Binary file build/arch/x86/realmode/rm/video-vesa.o matches Binary file build/arch/x86/realmode/rm/wakemain.o matches Binary file build/arch/x86/realmode/rm/regs.o matches Binary file build/arch/x86/realmode/rm/trampoline_64.o matches Binary file build/arch/x86/realmode/rm/wakeup_asm.o matches Binary file build/arch/x86/realmode/rm/copy.o matches Binary file build/arch/x86/realmode/rm/bioscall.o matches Binary file build/arch/x86/realmode/rm/reboot.o matches All the 32bit object files contain the full path, but none of the .cmd files do?! And we do trigger rebuild of a few files after moving the tree, but we do so even in the original location, so it looks like somebody got a custom rule wrong again. Michal