-
-
Notifications
You must be signed in to change notification settings - Fork 398
Feature Request: Export compile_commands.json #849
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think this is a cool idea, and I have wanted this feature. I think that it would be at least slightly complicated by how Arduino preprocesses the Without this preprocessing, IntelliSense, cheers |
I'm also interested in this feature, since my current manual compiler-flags configuration for code completion with As for the .ino file, it will indeed be pretty much impossible to let clangd see the preprocessed version, especially when you're editing it (unless the Arduino IDE talks to clangd and does the preprocessing on the fly, but that's not the subject of this issue). But I think it would actually be fine if all .ino files would end up in the compilation database with just the flags used to compile the preprocessed version. This means that if you have just a single .ino file (or multiple that do not depend on each other without forward declarations), and you do not depend on the autogenerated forward declarations (by defining functions in order and/or adding forward declarations manually), clangd should be able to figure things out most of the time. One additional thing is that preprocessing adds an So, outputting a compilation database would simply be a matter of dumping all compilation commands ran, and some special casing for the .ino files, which should be fairly easy to implement. Where should this file be generated? I suspect that the sketch directory is the obvious place, since that's also where editors / clangd will look for it, right? One thing to think about is partial compilation: When compilation fails, should a database be written with just the commands that were ran? Probably yes if no database existed yet, but what if a database was already present? Then it might be counterproductive to remove entries for files after the failure, since very likely the flags haven't changed. Maybe an existing database should be loaded, updated in memory and written out at the end of the compilation? If compilation failed, it should be written out as-is, if compilation succeeded, any files in the database that were no longer in the compilation should probably be pruned. |
I did a rough implementation of this feature, see the PR linked above. It's still far from finished, but it might serve to trigger some additional discussion. See the PR for a list of things I think need to be addressed. |
thank you @matthijskooijman enjoy the weekend |
Initial support of this has been merged in #1081. Since that merge, all compilations will generate a Some open points (notes copied from my earlier attempt in #944):
|
@matthijskooijman As an example, look at the compilation database, |
I see you opened #1286 for this, let's continue discussion there. |
I have an issue with this - if I compile using either of these options:
the associated build files are made and put in the local folder/whichever folder I tell it to build to, but To be clear: If I build using no additional flags like this (in the folder with
then the build files can be found in the system's temp folder and does include Here's the full command examples I've tried, but get no
Does this need it's own bug report or feature request? |
I'm having the same issue as @pokeymud. It's presenting for me in the official Microsoft Arduino VSCode Extension. |
Hi @pokeymud with
|
I had this issue and the following worked for me:
So thanks @umbynos! |
A useful enhancement to the arduino cli would be the option to generate a compile_commands.json file. This can be used by Microsoft's Visual Studio Code (vscode) application to configure the its' IntelliSense code completion, parameter info, quick info, and member lists capabilities. I find using arduino-cli and vscode is particularly productive for embedded development.
The text was updated successfully, but these errors were encountered: