Use relative path when creating include/asm/{mach,cpu} symlinks
PATCH 1/1 Use relative path when creating include/asm/{mach,cpu} symlinks
From: Franck Bui-Huu <[email protected]>
Usually relative paths are preferred because they survive directory moves, work across networked file systems/chrooted environments.
And in this case, there's no point to use absolute paths.
--- arch/sh/Makefile | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
arch/sh/Makefile +3 -4
@@ -164,7 +164,7 @@ include/asm-sh/.cpu: $(wildcard include/config/cpu/*.h) \ include/config/auto.conf FORCE @echo ' SYMLINK include/asm-sh/cpu -> include/asm-sh/$(cpuincdir-y)' $(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi - $(Q)ln -fsn $(incdir-prefix)$(cpuincdir-y) include/asm-sh/cpu + $(Q)ln -fsn $(cpuincdir-y) include/asm-sh/cpu @touch $@ # Most boards have their own mach directories. For the ones that
@@ -185,13 +185,12 @@ include/asm-sh/.mach: $(wildcard include/config/sh/*.h) \ if [ -d $(incdir-prefix)$$i ]; then \ echo -n ' SYMLINK include/asm-sh/mach -> '; \ echo -e "include/asm-sh/$$i"; \ - ln -fsn $(incdir-prefix)$$i \ - include/asm-sh/mach; \ + ln -fsn $$i include/asm-sh/mach; \ else \ if [ ! -d include/asm-sh/mach ]; then \ echo -n ' SYMLINK include/asm-sh/mach -> '; \ echo -e 'include/asm-sh'; \ - ln -fsn $(incdir-prefix) include/asm-sh/mach; \ + ln -fsn ../asm-sh include/asm-sh/mach; \ fi; \ fi; \ done
Signature · 1 line
1.5.4.4.GIT
Re: [PATCH] Use relative path when creating include/asm/{mach,cpu}
Quoted 6 lines · Franck Bui-Huu
From: Franck Bui-Huu <[email protected]>
Usually relative paths are preferred because they survive directory moves, work across networked file systems/chrooted environments.
And in this case, there's no point to use absolute paths.
I've not had a chance to check this, but are you sure this will work when building with O= (aka KBUILD_OUTPUT) set?
Stuart
Quoted 5 lines · Franck Bui-Huu
From: Franck Bui-Huu <[email protected]>
Usually relative paths are preferred because they survive directory moves, work across networked file systems/chrooted environments.
Usually, yes. But in this case, as Stuart noted, they are needed for out-of-tree builds.
It would be nice to get rid of the symlinks completely, and Sam had some ideas on how we could do that by doing a massive header reorganization, which is probably the way we'll go in the longer run. For now we just have to live with the obfuscation. Patches that clean it up without breaking existing behaviour are welcome, though.
Re: [PATCH] Use relative path when creating include/asm/{mach,cpu}
In reply to Franck Bui-HuuQuoted 4 lines · Stuart MENEFY
I've not had a chance to check this, but are you sure this will work when building with O= (aka
KBUILD_OUTPUT) set?
No I'm not sure at all ;)
Actually I've never used this building option and after a quick look the patch probably doesn't work as is.
Thanks
Franck
Re: [PATCH] Use relative path when creating include/asm/{mach,cpu}
In reply to Franck Bui-HuuQuoted 9 lines · Paul Mundt
Quoted 5 lines · Franck Bui-Huu
From: Franck Bui-Huu <[email protected]>
Usually relative paths are preferred because they survive directory moves, work across networked file systems/chrooted environments.
Usually, yes. But in this case, as Stuart noted, they are needed for out-of-tree builds.
Yes I've just checked and the patch won't work as is.
Quoted 3 lines
It would be nice to get rid of the symlinks completely, and Sam had some ideas on how we could do that by doing a massive header reorganization, which is probably the way we'll go in the longer run.
Sure, the patch I sent is just a 'fix' for building a kernel tree across NFS for example.
Quoted 3 lines
For now we just have to live with the obfuscation. Patches that clean it up without breaking existing behaviour are welcome, though.
Well it should be pretty trivial to make this patch works both cases although it can't be called a "clean up" patch.
Thanks,
Franck
Re: [PATCH] Use relative path when creating include/asm/{mach,cpu}
In reply to Franck Bui-HuuQuoted 3 lines · Franck Bui-Huu
Well it should be pretty trivial to make this patch works both cases although it can't be called a "clean up" patch.
and here's an updated patch, which should work for both cases.
It's pretty simple and not very intrusive so it could be a temporary fix until the massive header reorganization happen.
Franck
---8<---
Subject: [PATCH] Use relative path when creating include/asm/{mach,cpu} symlinks when possible
From: Franck Bui-Huu <[email protected]>
When building the kernel without passing the O= command line parameter there's no point to use absolute paths for them.
Usually relative paths are preferred because they survive directory moves, work across networked file systems and chrooted environments.
Absolute paths are still used if an output directory is given.
--- arch/sh/Makefile | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-)
arch/sh/Makefile +5 -2
@@ -154,7 +154,11 @@ drivers-$(CONFIG_OPROFILE) += arch/sh/oprofile/ boot := arch/sh/boot +ifneq ($(KBUILD_SRC),) incdir-prefix := $(srctree)/include/asm-sh/ +else +incdir-prefix :+endif # Update machine arch and proc symlinks if something which affects # them changed. We use .arch and .mach to indicate when they were
@@ -182,7 +186,7 @@ include/asm-sh/.mach: $(wildcard include/config/sh/*.h) \ $(Q)if [ ! -d include/asm-sh ]; then mkdir -p include/asm-sh; fi $(Q)rm -f include/asm-sh/mach $(Q)for i in $(incdir-y); do \ - if [ -d $(incdir-prefix)$$i ]; then \ + if [ -d $(srctree)/include/asm-sh/$$i ]; then \ echo -n ' SYMLINK include/asm-sh/mach -> '; \ echo -e "include/asm-sh/$$i"; \ ln -fsn $(incdir-prefix)$$i \
@@ -191,7 +195,7 @@ include/asm-sh/.mach: $(wildcard include/config/sh/*.h) \ if [ ! -d include/asm-sh/mach ]; then \ echo -n ' SYMLINK include/asm-sh/mach -> '; \ echo -e 'include/asm-sh'; \ - ln -fsn $(incdir-prefix) include/asm-sh/mach; \ + ln -fsn $(incdir-prefix)../asm-sh include/asm-sh/mach; \ fi; \ fi; \ done
Signature · 1 line
1.5.4.4.GIT
Quoted 10 lines · Franck Bui-Huu
Quoted 3 lines · Franck Bui-Huu
Well it should be pretty trivial to make this patch works both cases although it can't be called a "clean up" patch.
and here's an updated patch, which should work for both cases.
It's pretty simple and not very intrusive so it could be a temporary fix until the massive header reorganization happen.
Looks fine, and it works fine with both cases. I've applied it, thanks.