[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNASgxeOQmjXecd4Y3=Ne6Bd48WT4Un-z4M78noe+qYQ7_w@mail.gmail.com>
Date: Wed, 3 Jul 2024 02:46:53 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "nicolas@...sle.eu" <nicolas@...sle.eu>, "conor@...nel.org" <conor@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "robh@...nel.org" <robh@...nel.org>,
"krzk@...nel.org" <krzk@...nel.org>
Subject: Re: [PATCH v2 4/4] kbuild: use $(src) instead of $(srctree)/$(src)
for source directory
On Wed, Jul 3, 2024 at 1:15 AM Edgecombe, Rick P
<rick.p.edgecombe@...el.com> wrote:
>
> On Tue, 2024-07-02 at 18:15 +0900, Masahiro Yamada wrote:
> > > So there is no official way to build just a module to the output directory?
> >
> >
> > You already know how to do it:
> >
> > #I'm guess it has something to do with the "M=" option because:
> > #make ARCH=x86_64 O=../linux-tdx-kvm-out/ -j36 arch/x86/kvm/kvm.ko
> > #arch/x86/kvm/kvm-intel.ko
> > #
> > #...works.
>
> This can build just the module, but not clean just the module.
>
> >
> >
> >
> >
> > > And
> > > it just accidentally worked all these years? IMO it's a nice feature to
> > > have.
> > > I've especially found it useful when doing virtualization development where
> > > you
> > > need to build/test guest and host kernels as the same time.
> > >
> > > Or was it just now delegated to unofficial support after this patch?
> >
> >
> > No.
> > The M= option is intended for building external modules.
> > You just abused it to build the upstream modules.
> >
> > Kbuild has never supported building external modules in a separate
> > output directory.
> >
> >
> > "delegated to unofficial support" is a wrong statement,
> > as it has never officially supported in the past.
> >
> >
> > Your way is a workaround that people found happened to work.
>
> The main point is that the old behavior was useful. It seems the change that
> broke my workflow was intended to make it easier to maintain out-of-tree
> modules? If so then aren't we taking away useful behavior for in-tree module
> development to help out-of-tree modules?
No. I never meant to prioritize the external module builds.
I believe b1992c3772e69a6fd0e3fc81cd4d2820c8b6eca0 is the
right thing to do. That's all.
> Can you at least support VPATH method going forward? Although I am surprised I'm
> the only one that hit this. I assumed this was a common usage.
VPATH will be broken when a big change happens again
for external module builds.
That is what "unsupported" and "unofficial" mean.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists