compile_commands.json can be used with clangd to enable language server
protocol-based assistance. For kernel itself this can be built with
scripts/gen_compile_commands.py, but other projects (e.g., libbpf, or
BPF selftests) can benefit from their own compilation database file,
which can be generated successfully using external tools, like bear [0].

So, instead of adding compile_commands.json to .gitignore in respective
individual projects, let's just ignore it globally anywhere in Linux repo.

While at it, remove exactly such a local .gitignore rule under
tools/power/cpupower.

  [0] https://github.com/rizsotto/Bear

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
v1->v2:
  - clean up tools/power/cpupower's .gitignore (Miguel Ojeda).

 .gitignore                      | 2 +-
 tools/power/cpupower/.gitignore | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index bf5ee6e01cd4..451dff66275d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -175,7 +175,7 @@ x509.genkey
 *.kdev4
 
 # Clang's compilation database file
-/compile_commands.json
+compile_commands.json
 
 # Documentation toolchain
 sphinx_*/
diff --git a/tools/power/cpupower/.gitignore b/tools/power/cpupower/.gitignore
index 5113d5a7aee0..7677329c42a6 100644
--- a/tools/power/cpupower/.gitignore
+++ b/tools/power/cpupower/.gitignore
@@ -27,6 +27,3 @@ debug/i386/intel_gsic
 debug/i386/powernow-k8-decode
 debug/x86_64/centrino-decode
 debug/x86_64/powernow-k8-decode
-
-# Clang's compilation database file
-compile_commands.json
-- 
2.47.1

On Fri, 06 Jun 2025 14:48:40 -0700, Andrii Nakryiko wrote:
> compile_commands.json can be used with clangd to enable language server
> protocol-based assistance. For kernel itself this can be built with
> scripts/gen_compile_commands.py, but other projects (e.g., libbpf, or
> BPF selftests) can benefit from their own compilation database file,
> which can be generated successfully using external tools, like bear [0].
> 
> So, instead of adding compile_commands.json to .gitignore in respective
> individual projects, let's just ignore it globally anywhere in Linux repo.
> 
> [...]

Applied, thanks!

[1/1] .gitignore: ignore compile_commands.json globally
      https://git.kernel.org/kbuild/c/f7cc3caea0005

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>

On Fri, Jun 6, 2025 at 11:48 PM Andrii Nakryiko <andrii@kernel.org> wrote:
>
> compile_commands.json can be used with clangd to enable language server
> protocol-based assistance. For kernel itself this can be built with
> scripts/gen_compile_commands.py, but other projects (e.g., libbpf, or
> BPF selftests) can benefit from their own compilation database file,
> which can be generated successfully using external tools, like bear [0].
>
> So, instead of adding compile_commands.json to .gitignore in respective
> individual projects, let's just ignore it globally anywhere in Linux repo.
>
> While at it, remove exactly such a local .gitignore rule under
> tools/power/cpupower.
>
>   [0] https://github.com/rizsotto/Bear
>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Reviewed-by: Miguel Ojeda <ojeda@kernel.org>

Thanks!

Cheers,
Miguel

On Sat, Jun 7, 2025 at 2:27 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Jun 6, 2025 at 11:48 PM Andrii Nakryiko <andrii@kernel.org> wrote:
> >
> > compile_commands.json can be used with clangd to enable language server
> > protocol-based assistance. For kernel itself this can be built with
> > scripts/gen_compile_commands.py, but other projects (e.g., libbpf, or
> > BPF selftests) can benefit from their own compilation database file,
> > which can be generated successfully using external tools, like bear [0].
> >
> > So, instead of adding compile_commands.json to .gitignore in respective
> > individual projects, let's just ignore it globally anywhere in Linux repo.
> >
> > While at it, remove exactly such a local .gitignore rule under
> > tools/power/cpupower.
> >
> >   [0] https://github.com/rizsotto/Bear
> >
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
>

Masahiro,

Would you be able to pick this up? Or where should we route this
through, in your opinion? Thanks!

> Thanks!
>
> Cheers,
> Miguel

On Thu, Jun 12, 2025 at 1:28 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Sat, Jun 7, 2025 at 2:27 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Fri, Jun 6, 2025 at 11:48 PM Andrii Nakryiko <andrii@kernel.org> wrote:
> > >
> > > compile_commands.json can be used with clangd to enable language server
> > > protocol-based assistance. For kernel itself this can be built with
> > > scripts/gen_compile_commands.py, but other projects (e.g., libbpf, or
> > > BPF selftests) can benefit from their own compilation database file,
> > > which can be generated successfully using external tools, like bear [0].
> > >
> > > So, instead of adding compile_commands.json to .gitignore in respective
> > > individual projects, let's just ignore it globally anywhere in Linux repo.
> > >
> > > While at it, remove exactly such a local .gitignore rule under
> > > tools/power/cpupower.
> > >
> > >   [0] https://github.com/rizsotto/Bear
> > >
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > Suggested-by: Eduard Zingerman <eddyz87@gmail.com>
> > > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> >
> > Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> >
>
> Masahiro,
>
> Would you be able to pick this up? Or where should we route this
> through, in your opinion? Thanks!
>

Seems like this has fallen through the cracks... I guess we can take
it through the bpf-next tree, if there is no better home for this?

> > Thanks!
> >
> > Cheers,
> > Miguel

Hi Andrii,

On Tue, Aug 12, 2025 at 02:55:22PM -0700, Andrii Nakryiko wrote:
> Seems like this has fallen through the cracks... I guess we can take
> it through the bpf-next tree, if there is no better home for this?

Masahiro recently turned over maintenance of the Kbuild build tree as of
commit 8d6841d5cb20 ("MAINTAINERS: hand over Kbuild maintenance"). I am
happy to pick this up in the new Kbuild tree but I have no objections to
you taking it via BPF with

  Acked-by: Nathan Chancellor <nathan@kernel.org>

if you would like to. I suspect it matters most to the BPF folks anyways.

Cheers,
Nathan

On Tue, Aug 12, 2025 at 3:14 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Andrii,
>
> On Tue, Aug 12, 2025 at 02:55:22PM -0700, Andrii Nakryiko wrote:
> > Seems like this has fallen through the cracks... I guess we can take
> > it through the bpf-next tree, if there is no better home for this?
>
> Masahiro recently turned over maintenance of the Kbuild build tree as of
> commit 8d6841d5cb20 ("MAINTAINERS: hand over Kbuild maintenance"). I am
> happy to pick this up in the new Kbuild tree but I have no objections to
> you taking it via BPF with
>
>   Acked-by: Nathan Chancellor <nathan@kernel.org>
>
> if you would like to. I suspect it matters most to the BPF folks anyways.

I think the Kbuild tree makes most sense, as there is nothing BPF
specific here. I'm just carrying my custom compile_commands.json for
libbpf project and being careful about not accidentally committing it
(so far I managed), so I only want this to *eventually* make its way
into the kernel repo. Not urgent, though.

Please take it through the Kbuild tree then, thanks!

>
> Cheers,
> Nathan