linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Barker <paul@pbarker.dev>
To: Justin Stitt <justinstitt@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier	 <nicolas.schier@linux.dev>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	 Bill Wendling <morbo@google.com>,
	llvm@lists.linux.dev, linux-kbuild@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gen_compile_commands: Look in KBUILD_OUTPUT if set
Date: Fri, 05 Sep 2025 18:26:32 +0100	[thread overview]
Message-ID: <e09dce93d521a89e3820a91e7c319d680cae203f.camel@pbarker.dev> (raw)
In-Reply-To: <3fya5rij6amcwt36jthyezkzov44m6rdvlacymqfpbkcmzrnw4@fymsxhcqq6tj>

[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]

On Fri, 2025-09-05 at 09:34 -0700, Justin Stitt wrote:
> Hi,
> 
> On Fri, Sep 05, 2025 at 11:17:43AM +0100, Paul Barker wrote:
> > If someone is already using the KBUILD_OUTPUT environment variable to
> > specify the directory where object files are placed, they shouldn't need
> > to repeat the same information to gen_compile_commands.py.
> > 
> > Signed-off-by: Paul Barker <paul@pbarker.dev>
> > ---
> >  scripts/clang-tools/gen_compile_commands.py | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/scripts/clang-tools/gen_compile_commands.py b/scripts/clang-tools/gen_compile_commands.py
> > index 96e6e46ad1a702cb0fad5d524a9a02d222b236ec..7b94a2ffba0b4d5f1290b51bd602fb3f33acce6a 100755
> > --- a/scripts/clang-tools/gen_compile_commands.py
> > +++ b/scripts/clang-tools/gen_compile_commands.py
> > @@ -39,8 +39,9 @@ def parse_arguments():
> >      parser = argparse.ArgumentParser(description=usage)
> >  
> >      directory_help = ('specify the output directory used for the kernel build '
> > -                      '(defaults to the working directory)')
> > -    parser.add_argument('-d', '--directory', type=str, default='.',
> > +                      '(defaults to $KBUILD_OUTPUT (if set) or the working directory)')
> > +    parser.add_argument('-d', '--directory', type=str,
> > +                        default=os.environ.get('KBUILD_OUTPUT', '.'),
> >                          help=directory_help)
> >  
> >      output_help = ('path to the output command database (defaults to ' +
> > 
> 
> Thinking out loud: It might make sense to also change the default output
> path in some cases but not in all cases. For my clangd setup in vim, it
> does some discovery for a compile_commands.json and I have some
> different ones in various build-* directories -- I guess it'd be cool if
> they were automatically placed in their appropriate spot. With all that
> being said probably YAGNI.

I think it makes sense to place the output file in the current directory by
default if you run gen_compile_commands.py directly.

The `make compile_commands.json` target places it in the output directory, and
`make rust-analyzer` does the same for the rust-project.json file. I did think
about whether we should change these, since clangd and rust-analyzer look for
the relevant files in the source tree or its parent directories. But people may
be using multiple output directories for different configs or archs, so writing
the files to the source tree isn't a good default for everyone.

For my case I'm just symlinking the relevant files back in to the source tree
after building so that clangd and rust-analyzer can find them.

Thanks for testing!

-- 
Paul Barker

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

  reply	other threads:[~2025-09-05 17:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-05 10:17 [PATCH] gen_compile_commands: Look in KBUILD_OUTPUT if set Paul Barker
2025-09-05 16:34 ` Justin Stitt
2025-09-05 17:26   ` Paul Barker [this message]
2025-09-05 18:02     ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e09dce93d521a89e3820a91e7c319d680cae203f.camel@pbarker.dev \
    --to=paul@pbarker.dev \
    --cc=justinstitt@google.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=nicolas.schier@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).