search

Wumpf / IncludeToolbox

Visual Studio extension to format, prune, and inspect include directives.
https://marketplace.visualstudio.com/items?itemName=Wumpf.IncludeToolbox
MIT License
50 stars 22 forks source link

taken into account forcedincludes and propertysheets #40

Open jcageman opened 7 years ago

jcageman commented 7 years ago

Hi, i am making my own tool and came across the issue that people can also put forcedincludes in a project which are included in every file (precompiled headers for example). Your tool does not take those into account, but it gets even trickier when people start using propertysheets. You will get a value "$(INHERIT)" in the forced includes field, which is not resolved and you have to parse it yourself. To make your tool full-proof you have to parse the visual studio log files to get the exact compiler invocations. That is the only way i know how to do it.

Wumpf commented 7 years ago

I was not aware of any other "forced include" than pre-compiled headers. But googling for it brought up the -FI preprocessor option. Is that what you're aiming at? I'm not sure what it is that I need/can handle there in any of the Toolbox' tools. It does not affect sorting and can't be removed without touching project settings which I don't want to do. It might be worth considering putting those in the IncludeGraph and telling the IWYU integration somehow of it. I'm reluctant to do so as it might be confusing in the IncludeGraph and I'm not sure how to get this with IWYU working (which rarely works at all)

For pre-compiled headers there is an option in "Trial and Error Include" to ignore the first include. For the sorting in the formatter I recommend setting up your "Precedence Regexes" preference in a way that always puts the PCH first. I'm not sure which part of IncludeToolbox you mean by "your tool", since this is a collection of several ;-)

I also couldn't quite follow on this:

You will get a value "$(INHERIT)" in the forced includes field, which is not resolved and you have to parse it yourself. Are you implying that I need to do macro resolving on the -FI field if I want to use it, or what do you mean?

Thanks for your feedback so far!

jcageman commented 7 years ago

I am indeed aiming at the -FI preprocessor option. The reason i would need it is that without it some of my code does not compile (at my work we supply additional macro's for several uses with that method).

"$(INHERIT)" would indeed need macro resolving, but simply calling Evaluate() from VCConfiguration won't and will return empty result in my case. I ended up actually parsing the CL.command.1.tlog files for full compile argument information...