On Fri, Oct 4, 2024 at 4:47 AM Nicolas Schier <nicolas@xxxxxxxxx> wrote:
> > @@ -109,6 +109,9 @@ executed to make module versioning work.
> > directory where the external module (kbuild file) is
> > located.
> >
> > + MO=$BUILD_DIR
> > + Speficies a separate output directory for the external module.
>
> s/Speficies/Specifies/
Thanks, I will fix.
>
> > +
> > 2.3 Targets
> > ===========
> >
> > diff --git a/Makefile b/Makefile
> > index 9fbf7ef6e394..b654baa0763a 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -134,6 +134,10 @@ ifeq ("$(origin M)", "command line")
> > KBUILD_EXTMOD := $(M)
> > endif
> >
> > +ifeq ("$(origin MO)", "command line")
> > + KBUILD_EXTMOD_OUTPUT := $(MO)
> > +endif
> > +
> > $(if $(word 2, $(KBUILD_EXTMOD)), \
> > $(error building multiple external modules is not supported))
>
> Should we also check against multiple output directories?
I do not think so.
When a directory path contains a space,
it should be treated as-is, in general.
However, GNU Make is not good at handling spaces in files paths.
So, this will fail eventually (with a little more obscure way).
$ make O=build M=fs/btrfs MO='/tmp/AA BB/btffs'
Makefile:214: *** failed to create output directory "/tmp/AA BB/btffs". Stop.
> > -export building_out_of_srctree srctree VPATH
> > +ifeq ($(realpath $(_vpath)),$(CURDIR))
>
> Just a style consistency question: 'ifeq (,)' with a space after ',' (as a few
> lines above) or without as used here?
Maybe, we should keep consistency.
But, this line will be removed in v2.
--
Best Regards
Masahiro Yamada
