Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Make add-include style smarter

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
Flamefire Posted - Aug 14 2018 : 1:40:42 PM
I have set the include style to "context dependent" but on what context does it depend?

For example we have the usual convention of using "private.h" and <public.h>, <boost/foo.h> etc. But VA always adds headers with quotes only.

Given the problem with one-size-fits-all I'd suggest adding an option to specify a regex (or more) to decide which style to use.
12   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Aug 20 2018 : 07:14:05 AM
That makes sense. It seemed like a possible work around, but as you say, it's not really going to work so well. I have put in a feature request for a list of directories that should always use angle brackets for add include:

case=118472

The simple approach is just a list of directories, as if they were stored in:

Project properties -> VC++ Directories -> Include Directories

regardless of where they are stored in the project settings. A more flexible approach is the registry key settings Sean suggested.
Flamefire Posted - Aug 19 2018 : 07:40:20 AM
That's why I suggested the RegExp based approach. E.g. clang-format (and others) use this to let the user customize include ordering.

Not really for 2 reasons: `INCLUDE_DIRECTORIES` shouldn't be used anyway, but rather `target_include_directories` and even that is deprecated in favor of simply "linking" against boost: `target_link_libraries(myExe boost::filesystem)`. This propagates the includes automatically, so one does not have to mess with all those paths.
And 2: You don't want to set this twice: Once for VS and once for "regular" compilers. One could of course set the property additionally, but it seems it is a global one, not per target, which is/can be bad.
Oh and on top of this it is CMake 3.12.x where this was introduced. Might be ok, as locally one can install the newer CMake, but I'd rather stay with the "project CMake version", to avoid using features, which are not supported by the build server.
feline Posted - Aug 18 2018 : 12:09:40 PM
I am wary about trying to get to clever with rules for which brackets to use, since sometimes solutions contain "stable library code" as part of the solution, so this may include examples of external header files being included with "". CMake feels really confusing, but after some experimenting, I got the same result, and for me the trick was to add the boost include to the CMakeLists.txt file with:

SET ( CMAKE_VS_SDK_INCLUDE_DIRECTORIES C:/boost/boost_1_60_0 )

rather than the expected INCLUDE_DIRECTORIES() command. Is this a workable solution for you? Once you have re-run cmake to regenerate your Visual Studio solution, VA will know, based on the directory settings, which type of include statement to use for boost header files.
Flamefire Posted - Aug 17 2018 : 1:43:00 PM
I'd probably go for only 1 of them as "no match" is the same as a match in the other.

Maybe one could also make the "context based" one smarter. Most includes are of the form `libY/header.h`. When VAX analyzes the project, it can base the decision, which brackets to use, on how other headers of the same "libY" are included. So if all/most are `#include <boost/header.h>` then every new boost header will have angle brackets. This could also be used to avoid adding includes like `#include "../../dir/libX/foo.h"` when there are already includes `#include "libX/bar.h"`

Boost is installed "system-wide" (e.g. C:\boost), so no.

@feline: No (see above). VS does not have this concept as it seems. But I just found there is CMAKE_VS_SDK_INCLUDE_DIRECTORIES which can override the "VC++ Directories | Include Directories". Not sure why this isn't used for SYSTEM though.
feline Posted - Aug 17 2018 : 08:13:25 AM
Does the [SYSTEM] flag for the include directories in CMake have any effect here? From the description here:

https://cmake.org/cmake/help/v3.0/command/include_directories.html

I would hope that it told CMake to place the system include directories into a different setting for Visual Studio, but it doesn't make it clear if that will happen or not.
sean Posted - Aug 15 2018 : 5:31:51 PM
I see -- so you would associate that regex with a setting like "IncludeDirectiveForceAngleOnRegexMatch" and there would be a separate one for "IncludeDirectiveForceQuoteOnRegexMatch"? And I guess one would get priority over the other if both resulted in a match.

Are your boost directories in source control? If so, are they 'under' your project directory or are they in something like a parallel or sibling directory?
Flamefire Posted - Aug 15 2018 : 4:59:02 PM
Maybe something like: `(boost/)|(^[^.]+$)` (All from boost and everything w/o an extension)
sean Posted - Aug 15 2018 : 3:05:42 PM
If you could use a regex to decide which style to use, what would it look like?
Flamefire Posted - Aug 15 2018 : 2:50:50 PM
The project is CMake generated, so they are added to "Additional Include Directories". Seems like the VS generator does not differentiate between system and non-system includes
sean Posted - Aug 15 2018 : 1:38:53 PM
Are the boost directories added to include paths via:
Project Properties | Configuration Properties | VC++ Directories | Include Directories
or
Project Properties | Configuration Properties | C/C++ | Additional Include Directories

VC++ Directories will default to <> while Additional Include Directories default to "". But that is just a starting point. There are other rules / heuristics / vagaries* that come into play.

*Kramer: "Well, it seems that, uh, due to the vagaries of the production parameters, vis-�-vis the fragmenting of the..."
https://www.reddit.com/r/seinfeld/comments/ibt3u/well_it_seems_that_uh_due_to_the_vagaries_of_the/
Flamefire Posted - Aug 15 2018 : 12:20:36 PM
The page does not help at all unfortunately. It basically says the same as the tooltip: It decides based on context

You are right though about system headers, they are added correctly.
But e.g. boost headers are not. Boost is added via the include paths of the project and there already is a line like `#include <boost/foo.hpp>` along others (including a local include with quotes)

So at what exactly is VA looking? And what is it looking for?
feline Posted - Aug 14 2018 : 2:38:17 PM
This page may help to explain things a bit:

https://docs.wholetomato.com/default.asp?W177

VA looks at the existing #include lines in the file to tell it about / vs
Have you ever used VA to add a #include for something that is clearly a system header? For example "std::map"? For me this adds #include <map>, while a local header file is added with double quotes.

To work out if its double quotes or angle brackets we will be looking at your include directory settings, to see which directory the header file is in, so which type of include we should be using.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000