| Message ID | 1404887241-14455-1-git-send-email-yamada.m@jp.panasonic.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2014-07-09 08:27, Masahiro Yamada wrote: > Since commit 9da0763bd, the variable 'srctree' is set as follows: > > [1] Building in the source tree > => srctree is set to '.' > [2] Building in a subdir right under the source tree > => srctree is set to '..' > [3] Other cases > => srctree is set to the absolute path to the source tree > > Pros are more readable compiler messages, WARN_ON() etc. > for case [1] and [2]. (but not [3]) > > Cons are we have to do build-test for 3 cases when adding > some changes to the build infrastructure. > > We want to treat case [2] and [3] in the same way like prior to > commit 9da0763bd, keeping the compact log messages. > > The idea here is to create a symbolic link 'srctree' pointing > to $(KBUILD_SRC) at the very early stage of the build process. If the symlink points to an absolute path, then you can't move the source and build tree around anymore. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michal, On Wed, 09 Jul 2014 10:59:59 +0200 Michal Marek <mmarek@suse.cz> wrote: > On 2014-07-09 08:27, Masahiro Yamada wrote: > > Since commit 9da0763bd, the variable 'srctree' is set as follows: > > > > [1] Building in the source tree > > => srctree is set to '.' > > [2] Building in a subdir right under the source tree > > => srctree is set to '..' > > [3] Other cases > > => srctree is set to the absolute path to the source tree > > > > Pros are more readable compiler messages, WARN_ON() etc. > > for case [1] and [2]. (but not [3]) > > > > Cons are we have to do build-test for 3 cases when adding > > some changes to the build infrastructure. > > > > We want to treat case [2] and [3] in the same way like prior to > > commit 9da0763bd, keeping the compact log messages. > > > > The idea here is to create a symbolic link 'srctree' pointing > > to $(KBUILD_SRC) at the very early stage of the build process. > > If the symlink points to an absolute path, then you can't move the > source and build tree around anymore. In which cases do we need to do this? Anyway, even if we move the source and build tree around, it is much faster to rebuild it. The point here is that the absolute paths do not appear in .*.cmd files. For example, $ make O=foo/bar defconfig all [ full build ] $ cd .. $ mkdir baz $ move linux baz $ cd baz/linux $ make O=foo/bar [ much faster re-build ] Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-07-09 11:25, Masahiro Yamada wrote: > Hi Michal, > > > On Wed, 09 Jul 2014 10:59:59 +0200 > Michal Marek <mmarek@suse.cz> wrote: > >> On 2014-07-09 08:27, Masahiro Yamada wrote: >>> Since commit 9da0763bd, the variable 'srctree' is set as follows: >>> >>> [1] Building in the source tree >>> => srctree is set to '.' >>> [2] Building in a subdir right under the source tree >>> => srctree is set to '..' >>> [3] Other cases >>> => srctree is set to the absolute path to the source tree >>> >>> Pros are more readable compiler messages, WARN_ON() etc. >>> for case [1] and [2]. (but not [3]) >>> >>> Cons are we have to do build-test for 3 cases when adding >>> some changes to the build infrastructure. >>> >>> We want to treat case [2] and [3] in the same way like prior to >>> commit 9da0763bd, keeping the compact log messages. >>> >>> The idea here is to create a symbolic link 'srctree' pointing >>> to $(KBUILD_SRC) at the very early stage of the build process. >> >> If the symlink points to an absolute path, then you can't move the >> source and build tree around anymore. > > > In which cases do we need to do this? Sorry for the late response. You might want to nfs-export the build and source tree and mount it on a different machine. Up to 3.16, one had to make sure that the paths match on both machines. 3.16 removes this limitation. > Anyway, even if we move the source and build tree around, > it is much faster to rebuild it. > > The point here is that the absolute paths do not appear > in .*.cmd files. If you either do not use O= or use O=<subdir>, then there won't be any absolute paths either. It could be extended to handle O=subdir1/subdir1/... if needed. > For example, > > $ make O=foo/bar defconfig all > [ full build ] > $ cd .. > $ mkdir baz > $ move linux baz > $ cd baz/linux > $ make O=foo/bar > [ much faster re-build ] I now noticed that the patch unconditionally recreates the symlink on every make O= invocation. While this nicely fixes the problem with moved build directory, it also means that a 'make O=... modules_install' ran as root will try to recreate the symlink. This will fail on nfs. So I'd rather keep the current logic with $(SRCTREE) containing either an absolute or relative path. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Makefile b/Makefile index 4d75b4b..0089618 100644 --- a/Makefile +++ b/Makefile @@ -130,6 +130,7 @@ $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make # able to understand relative filenames. sub-make: FORCE @echo "make[1]: Entering directory \`$(KBUILD_OUTPUT)'" + $(if $(KBUILD_VERBOSE:1=),@)ln -fsn $(CURDIR) $(KBUILD_OUTPUT)/srctree $(if $(KBUILD_VERBOSE:1=),@)$(MAKE) -C $(KBUILD_OUTPUT) \ KBUILD_SRC=$(CURDIR) \ KBUILD_EXTMOD="$(KBUILD_EXTMOD)" -f $(CURDIR)/Makefile \ @@ -152,17 +153,7 @@ else _all: modules endif -ifeq ($(KBUILD_SRC),) - # building in the source tree - srctree := . -else - ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR))) - # building in a subdirectory of the source tree - srctree := .. - else - srctree := $(KBUILD_SRC) - endif -endif +srctree := $(if $(KBUILD_SRC),srctree,.) objtree := . src := $(srctree) obj := $(objtree) @@ -460,7 +451,6 @@ PHONY += outputmakefile # output directory. outputmakefile: ifneq ($(KBUILD_SRC),) - $(Q)ln -fsn $(srctree) source $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \ $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL) endif
Since commit 9da0763bd, the variable 'srctree' is set as follows: [1] Building in the source tree => srctree is set to '.' [2] Building in a subdir right under the source tree => srctree is set to '..' [3] Other cases => srctree is set to the absolute path to the source tree Pros are more readable compiler messages, WARN_ON() etc. for case [1] and [2]. (but not [3]) Cons are we have to do build-test for 3 cases when adding some changes to the build infrastructure. We want to treat case [2] and [3] in the same way like prior to commit 9da0763bd, keeping the compact log messages. The idea here is to create a symbolic link 'srctree' pointing to $(KBUILD_SRC) at the very early stage of the build process. We created the symbolic link 'source' in outputmakefile: target, but it is redundant and should be removed. (I think 'srctree' is a more suitable symbolic link name than 'source') Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Sam Ravnborg <sam@ravnborg.org> --- Makefile | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-)