Message ID | 20210120193100.3414664-1-masahiroy@kernel.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | kbuild: warn a relative path used for M= in out-of-tree builds | expand |
CC: kernel-team@android.com Thanks Masahiro! I'd like to also note that the Android kernel build system is leveraging this behaviour as sort of an "O=" for external modules [1]. This way the external module's build artifacts are contained separate from the kernel build artifacts and the module's source code. --Will [1] https://android.googlesource.com/kernel/build/+/refs/heads/master/build.sh#748 On Wed, Jan 20, 2021 at 11:31 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > Surprising to me, Kbuild can handle a relative M= path while having > in-kernel objects in a separate directory. In this case, the M= option > actually defines: > > - the path to external module sources relative to $(srctree) > - the path to external module objects relative to $(objtree) > > For example, > > make O=foo/bar M=baz > > ... will find the source files in baz, and create objects in foo/bar/baz. > > Currently, it works like that because of the presence of VPATH and > --include-dir=$(abs_srctree), but this behavior is subtle and cannot > be guaranteed in the future. I do not know if it was even officially > supported ever. > > I do not recommend this usage. > > Reported-by: Will McVicker <willmcvicker@google.com> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > Makefile | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Makefile b/Makefile > index b0e4767735dc..e42a27447eae 100644 > --- a/Makefile > +++ b/Makefile > @@ -1699,6 +1699,13 @@ else # KBUILD_EXTMOD > # Install the modules built in the module directory > # Assumes install directory is already created > > +ifdef building_out_of_srctree > +ifneq ($(filter-out /%, $(KBUILD_EXTMOD)),) > +$(warning The combination of out-of-tree build and relative M= path is not well supported.) > +$(warning Please do not complain about any trouble happening under this circumstance.) > +endif > +endif > + > # We are always building only modules. > KBUILD_BUILTIN := > KBUILD_MODULES := 1 > -- > 2.27.0 >
diff --git a/Makefile b/Makefile index b0e4767735dc..e42a27447eae 100644 --- a/Makefile +++ b/Makefile @@ -1699,6 +1699,13 @@ else # KBUILD_EXTMOD # Install the modules built in the module directory # Assumes install directory is already created +ifdef building_out_of_srctree +ifneq ($(filter-out /%, $(KBUILD_EXTMOD)),) +$(warning The combination of out-of-tree build and relative M= path is not well supported.) +$(warning Please do not complain about any trouble happening under this circumstance.) +endif +endif + # We are always building only modules. KBUILD_BUILTIN := KBUILD_MODULES := 1
Surprising to me, Kbuild can handle a relative M= path while having in-kernel objects in a separate directory. In this case, the M= option actually defines: - the path to external module sources relative to $(srctree) - the path to external module objects relative to $(objtree) For example, make O=foo/bar M=baz ... will find the source files in baz, and create objects in foo/bar/baz. Currently, it works like that because of the presence of VPATH and --include-dir=$(abs_srctree), but this behavior is subtle and cannot be guaranteed in the future. I do not know if it was even officially supported ever. I do not recommend this usage. Reported-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> --- Makefile | 7 +++++++ 1 file changed, 7 insertions(+)