[llvm-dev] Properly configuring vscode for LLVM development

Stella Laurenzo via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 1 06:51:50 PST 2021


On Wed, Dec 1, 2021, 6:41 AM Nicolas Vasilache via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi everyone,
>
> I am trying to use vscode for cmake development and so far I have been
> only moderately successful.
>
> I think I have most of the things right (including clangd and
> autocomplete) but I still have a few issues:
>
> 1. I am not able to configure vscode + cmake such that the project only
> rebuilds incrementally. As a consequence a tiny change retriggers
> compilation of the whole thing. Since I configured ccache I get close to
> 100% hits but this still takes ~1-2 minutes instead of a few seconds by
> using cmake -Ninja on the command line.
> (I think) I have been careful to not trigger spurious stuff (e.g.)
>
>     "cmake.generator": "Ninja",
>     "cmake.clearOutputBeforeBuild": false,
>     "cmake.configureOnEdit": false,
>     "cmake.exportCompileCommandsFile": false,
>     "cmake.autoSelectActiveFolder": false,
>     "cmake.useCMakePresets": "never",
>
> but to no avail ..
>
> The other 2 may be related to my not investing the time to dig further
> until I have a proper solution to point 1.
>

This is a big between cmake/ninja/debian distros/vscode that is quite
unfortunate. I root caused it a year ago here, and the quick fix for vscode
config is noted just after my response:
https://gitlab.kitware.com/cmake/cmake/-/issues/17330

(Ftr - I don't use vscode cmake integration. I'm too addicted to having
command line control)


> 2. I am not sure how to set the tests for easily pinpointing particular
> errors, running a single test through the IDE and fixing it inline. Maybe
> we are spoiled but our internal Google setup makes it very easy to do such
> things.
>

I think this is screaming for an extension for lit that to my knowledge
does not exist. Probably not the right person to comment on that because...
CLI bias again.



> 3. I am not sure how to set up the integrated debugger to have a clicky
> debugging nice setup. I have some old recollections circa VC++ 6.0 ish
> where these things were quite nice to navigate and I am hoping to
>

My life improved substantially when I switched to one of the lldb plugins
from the default provided gdb plugin. Especially for llvm, gdb is just too
slow to launch. I don't love hand coding launch configs in json but it is
serviceable, and that is the one manual step (basically just the path to
binary and args), and it should be clicky from there. I believe there are
various things floating around to make llvm types a bit nicer in the
debugger but I just squint :/



> Some additional details that may be of relevanceL
> A. I am on a Linux boc (and running through a remote connection from my
> mac laptop).
> B. I am using a third-party project and I am making use of some MLIR side
> features to build stuff
> together with LLVM. In particular:
>     "cmake.sourceDirectory": "${workspaceFolder}/../llvm-project/llvm",
> Note that this is not a problem in my CLI-only setup where things behave
> like I expect them
>
> Does anyone know of a good setup I could replicate?
>
> If you're replying to this, please +1 me in the conversation because email
> is hard.
>
> Thanks much!
>
> --
> N
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211201/a93ce9d8/attachment.html>


More information about the llvm-dev mailing list