Generate c_cpp_properties.json

[Raspredval]

Regarding the header, it is by design that we don't see it when standalone but only when included in another c/c++ source file because only then it becomes a translation unit. Any design change regarding how IntelliSense works for standalone headers would belong to CppTools (our sister extension), not Makefile Tools.

Originally posted by @andreeis in https://github.com/microsoft/vscode-makefile-tools/issues/433#issuecomment-1476847968

So, my issue was that make extention didn't extract some configs from the makefile. The way the export works right now is that make extension tries to parse the makefile and extract as much info as possible. Next it would pass that info to the intellisence. But by doing so it overrides the user's configs. And if the extention failes to parse the info it would just supply the default values (and not even default values listed in the global user config, THE default values). What would be great if there was a toggle right in the extention GUI that would allow users to just copy all configs from the makefile that it managed to parse correctly into a local c_cpp_properties.json config file and just use that. That would allow the user to manually fix something if there's a need for it. If I understand it right, the source for config profiles is specified in the local settings.json file as "C_Cpp.default.configurationProvider" field. So by default the extension sets this field as "ms-vscode.makefile-tools". Now, if there was this toggle and the user toggled it off, the extension would just need to copy every info it gathered from the makefile and then clear the "C_Cpp.default.configurationProvider" field and vice versa. Seems like a pretty easy solution that would satisfy a lot of users dealing with some weird/not yet implemented behavior of the extension

[andreeis]

@Raspredval , thank you for the feature idea. We may not get to implement this immediately but we will triage and address it in future, also based on the reactions from the community. In the meantime, something similar that we already have implemented, is a command that generates compile_commands.json. Does this help in any way for now?

[duaneellissd]

can you explain this more?

i have a makefile that i generate that intellisense cannot figure out

its not just 1 makefile but there are numerous included makefiles and i use a number of gnumake tricks to compute things and i do not think the make parser understands this (in total the combined generated makefiles are probably 2 megabytes and span 10 to 15 directories, the hand created make parts are probably 250k with the balance 9over 2meg) generated by my python scripts (i am not using cmake)

the result is intellisense does not work and i wish it would.

[andreeis]

@duaneellissd, this sounds interesting, let's get your project set up properly so that you actually get all the benefits of IntelliSense and of any other features that we provide.

Set in your .vscode/settings.json: "makefile.loggingLevel": "Debug", "makefile.extensionOutputFolder": "./MyOutputFolder", "makefile.extensionLog": "extension.log"

Reload your project after you make sure all the makefiles are generated and in their place. Once the "configure" phase finishes (you can see "Configure finished" in the "Makefile Tools" output channel), share with us from the ./MyOutputFolder the files dryrun.log and extension.log.

If your project happens to be open source, point us to it and we can clone and set it up without going back and forth and I can let you know about the final solution.

[andreeis]

@duaneellissd, you are not the original creator of this ticket, so most probably we'll end up investigating your specific situation from within a different GitHub issue. This 439 can remain to track the original suggestion.

[duaneellissd]

Note some ideas for you

I am not saying you need to do it this way but understanding this technique might help in other ways

first technique:

if the user specifies the compiler type and perhaps the name (example the compiler is really gcc but it has a funny name your tool does not recognize and cannot figure out) because it is suppressed

another thing is sometimes the make log is not verbose enough to parse easily or is too verbose

the static code analogy’s tool coverity from synopsis has a feature that solves a lot of this very well

it discovers the compiler configuration for each file built from the makefile or what ever you use to build it works with any tool any make system an even if you use a shell script or something like python scons

they do this by wrapping the make execution capturing the call to exec when the make program or one of the child processes or shell script launches gcc via the exec system call

sort of like how the Linux tool strace works

Try: strace -o tracefile -ff make

Then look at the created trace files

By doing that coverity can track compilers launched via complex shell scripts or make files or from python (scons) and it works even if these scripts change the current directory or apply different command line options that are unique to each file

they need to do this because their customers often cannot share the software or discuss details because the work is in a top secret classified area or room and the tool has to work

developers in that world do some weird stuff that breaks lots of stuff

in the end the coverity tool writes a data base entry for each file then when it is done you run another tool that rebuilds the application using the coverity tool applying the settings captures during the compilation process

=========

a second technique would be to require some special make targets that vscode can use to extract information like “make vscode.print.cflags” or “make vscode.print.srcdirs”

The user could then make those targets work

these should create a file ( do not parse stdout because there might be extra crap printed by the build system the user cannot control)

As a challenge make this work with something like the Linux kernel build system or the configure make build process for gcc because there are so many configuration options

[andreeis]

@duaneellissd , thank you for the ideas, very interesting :). About compiler with unusual names, just know that we have the setting "makefile.additionalCompilerNames" as array of string. You did not provide the logs we requested, is it because you fall into the scenario of too cryptic build output? Which inspired your first idea with the traces?

[duaneellissd]

the work i do does not allow me to disclose that level of detail. if you have ever worked in a place like that you would understand the limitations

about the trace method i use the tool coverity in my work along with other tools like blackduck, and “understand” by sci tools, we use multiple static code analysis tools including visual studios built in static analysis tools

while i do not work in NASA class A software, it is very close to that level of rigor. (fyi nasa class A software means your software failure puts human life at risk, there is a very different level of inspection and test that you face. ie think about the software inside a heart pace maker implanted in your child’s chest, you will take no chances)

its funny how some tools (and support people)just do not work unless they have full on network up and running. it is painful at times getting an isolated system to work

[andreeis]

@duaneellissd, totally understand. Thank you for the ideas again. From your situation (and others similar) I will think what we can do to be able to apply some processing on logs for such code bases to hide sensitive data and so that more of our users are able to share for diagnostics.