Works for me and it was on my wish list. Same tgz attached. I prefer DIST_TUPLE but I guess either way is ok (GH* vs DIST_TUPLE github).
> 1) To make compile_commands.json file for OpenBSD kernel use: > > cd /sys/arch/$(machine)/compile/GENERIC.MP > make -n | compiledb > mv compile_commands.json /sys I know nothing about clangd but tried with clang-tools-extra-16.0.6 & my wip vscode/-clangd-cdtcloud. Looks like clangd starts in a new context so I had to bump datasize-cur to 3G. The default staff limit, then 2G, wasn't enough for indexing. Did you tried on src ? Is there a solution to fake build ? cd /usr/src make obj make | compiledb I played a little with the two compile_commands.json in same workspace (the reason I choose cdtcloud fork of vscode-clangd is two handle multiple project). I did not test 'make tags' from faq so I have no idea which features clangd bring compared to those tags. This isn't perfect but it works. One example, in userland, I went for getchar() definition, then getc(), it only find the macro definition and wasn't able to understand the nested getc is the actual function so it wasn't able to lead me to the actual implementation. Perhaps its related to vscode. There are other issues with clangd but this is unrealted to this port. I think this port is usefull to play with clangd. On 10/05/2024 11:37, Mikhail wrote: > Up. > > Tests pass. > > On Fri, 3 May 2024 at 11:35, Mikhail Pchelin <mi...@freebsd.org > <mailto:mi...@freebsd.org>> wrote: > > I wasn't able to google how to generate compile_commands.json file for > the kernel to make clangd/LSP/vim work. > > It looks like the most used tool is a bear > (https://github.com/rizsotto/Bear <https://github.com/rizsotto/Bear>), but > during initial porting efforts I > found out that it doesn't work, I got constant crashes and pinsyscalls > messages in dmesg. > > compiledb is a much simpler python tool which parses gmake logs and > generates compile_commands.json file, it also works fine with the > OpenBSD kernel, which was the main motivation, I also tried jumping > around emacs sources - works fine, using option 3 from the README. > > Fail of option 2 for emacs is documented in make.py file of the > distribution, but I wasn't able to make the workaround fix it, given the > option 3, which works, seems not a bid deal? > > Thoughts? > > $ pkg_info compiledb-0.10.1 > Information for inst:compiledb-0.10.1 > > Comment: > compile_commands.json generator > > Description: > Tool for generating Clang's JSON Compilation Database file for GNU > make-based > build systems. > > Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org > <mailto:ports@openbsd.org>> > > WWW: https://github.com/nickdiego/compiledb > <https://github.com/nickdiego/compiledb> > > $ cat /usr/local/share/doc/pkg-readmes/compiledb > > +------------------------------------------------------------------------------- > | Running compiledb on OpenBSD > > +------------------------------------------------------------------------------- > > compiledb supports only gmake for native compile_commands.json file > generation, > but you can try to feed usual make output to it through a pipe, or --parse > option. > > Examples: > > 1) To make compile_commands.json file for OpenBSD kernel use: > > cd /sys/arch/$(machine)/compile/GENERIC.MP <http://GENERIC.MP> > make -n | compiledb > mv compile_commands.json /sys > > 2) To get compilation db for another software, which uses gmake pass -c > option > for make subcommand: > > cd ~/work/software > compiledb -n make -c gmake > > 3) Above command runs 'gmake -Bnwk' and parses output, if your software > uses > autotools and enters endless ./configure stage, try removing -B switch > and pipe > the output without it: > > gmake -nwk | compiledb >
compiledb.tgz
Description: application/compressed-tar
