labath added a comment. In D70886#1767654 <https://reviews.llvm.org/D70886#1767654>, @aadsm wrote:
> > Maybe you could do something similar to LocalLLDBInit.test ? > > That test uses the `lldb` `-S` (and others) flags that `lldb-vscode` doesn't > support :(. These flags should really be added to the initialize packet but > they're very specific to lldb and the DAP doesn't support it.. We could > implement something like what `Driver::ProcessArgs` does and pass options > through envs but, the logic in ProcessArgs itself is sketchy (just like the > comment mentions) and I l also find it odd to pass options through env vars... I was specifically referring to the part where the test sets up an `.lldbinit` in a random directory and then points the HOME environment variable there in order to "trick" lldb into executing it. It's true that the test also uses `-S`/`--source-before-file`, but nothing in there is really needed to test this functionality (i.e., making sure that lldb-vscode handles the lldbinit file reasonably -- making sure that it does not get confused by ambient lldbinit files is a different topic). As for -no-lldbinit functionality, all of the proposed solutions (cmdline flag, environment variable, protocol flag...) seem reasonable to me. The environment variable is probably easiest to implement, and should be sufficient if we only want to use this for testing.... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70886/new/ https://reviews.llvm.org/D70886 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
