search

dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.56k stars 1.44k forks source link

Support compile_flags.txt with clang-based tools #2831

Open sam-lunt opened 5 years ago

sam-lunt commented 5 years ago

Clang-based tools also support a file compile_flags.txt, which is a simpler alternative to a full compile_commands.json file (see here). However, the ale#c#FindProjectRoot function does not attempt to locate such a file, since ale#c#FindCompileCommands does not look for compile_flags.txt.

This seems like an easy feature to add, and I'd be happy to do it. The only question I had was whether this should be made in FindCompileCommands or in FindProjectRoot (or neither). Changing FindCompileCommands would require the smallest diff, but it would also make the name slightly misleading. It also might break some other user of the function.

The main impetus for this is that it doesn't seem like clangd will start if ALE cannot find a compile_commands.json file to use, even if there is a compile_flags.txt file available. (Also, clangd can provide useful results even without a compilation database present. Is there a way to force it to be started?)

w0rp commented 5 years ago

One way you make sure any language server is started is to configure ale_lsp_root for your project to indicate where the project root is.

proxict commented 4 years ago

I second this request. It would possibly be enough to just make the this variable configurable: https://github.com/dense-analysis/ale/blob/c2b01f0e28b4f007d01373821ba19dcfa440f9c2/autoload/ale/c.vim#L9 Right now, the workaround is to create one of the files from the list ('.git/HEAD', 'configure', 'Makefile', 'CMakeLists.txt') as a dummy file in the project root.

w0rp commented 4 years ago

I would like to see a PR for parsing compile_flags.txt, which should be similar to parsing command keys from compile_commands.json. We could make our lives easy by reading the lines of output and converting them into the same JSON Dictionaries we get from compile_commands.json. We should always prefer compile_commands.json over compile_flags.txt, because the quoting of arguments will be better if the arguments keys are used in output, say from Bear.