| Author |
 Topic  |
|
|
Flamefire
New Member
7 Posts |
 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. |
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
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. |
zen is the art of being at one with the two'ness |
 |
|
|
Flamefire
New Member
7 Posts |
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? |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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
New Member
7 Posts |
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
Whole Tomato Software
USA
2817 Posts |
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
New Member
7 Posts |
Posted - Aug 15 2018 : 4:59:02 PM
|
| Maybe something like: `(boost/)|(^[^.]+$)` (All from boost and everything w/o an extension) |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
Flamefire
New Member
7 Posts |
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
Whole Tomato Software
United Kingdom
19024 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
Flamefire
New Member
7 Posts |
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
Whole Tomato Software
United Kingdom
19024 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Make add-include style smarter
