Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 No autocomplete with vcpkg

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
SimonR_ Posted - Jul 18 2020 : 08:04:57 AM
Hello,
I've just installed Visual Assist 10.9.2382 and I noticed vcpkg is not working correctly. There is no autocomplete (also for header files), namespaces are not colored correctly. In general, most Visual Assists features do not work properly.

No autocomplete for headers


No color for namespaces


What should I do? It's definitely a Visual Assist error, as it works fine with IntelliSense. Maybe it's because vcpkg is on another drive?

11   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Mar 18 2022 : 07:26:30 AM
We generally try to avoid extra settings that you need to set yourself, the goal is to have VA "just work". It doesn't always happen, but we do try. Still, its a fair point, and I will add a note about this to the case, that might help.

Stable include directories are global in the sense that if VA has parsed them once for one project then they don't need to be parsed again for a different project. But they are not global in sense that just because one project includes a given directory we assume all projects will include that directory.

Of course all of this assumes that VA can correctly pick up the required settings from your project.
hajokirchhoff Posted - Mar 16 2022 : 07:23:51 AM
quote:
Originally posted by feline
...currently it rarely comes up, so apparently VCPKG isn't that widely used by our users. ...


Not yet widely used, but vcpkg is so good, expect to see more of it in the future.

I am using vcpkg (Version 2022) in manifest mode. This version inserts its vcpkg.build.props and vcpkg.target.props scripts into the MSBuild toolchain and modifies the "ExternalDirectories" MSBuild Property (External Include Paths in the Settings page). In manifest mode, each project can have it's own version of the "ExternalDirectories" Include path.

vcpkg in manifest mode is the easiest way I have found (ever) to use different versions of the boost libraries (or any other of the 1900+ libs). Since the versions will differ from project to project, vcpkg include paths should probably not be considered global include directories. Additionally, the files can/will also change depending on the concrete project toolchain and debug/release version, although that is probably less of an issue for VisualAssist.

What VisualAssist probably should do is somehow evaluate the ExternalDirectory value for the project and use this as a project specific include directory. Or alternatively I'd be fine with an additional visualassist.json configuration file specifying include directories for the project. I'd like an additional (json) file because I can easily include that in a repository.

So effectively I'd like to have an additional "stable include directory" *per* *project*.
feline Posted - Jan 31 2022 : 1:03:13 PM
The problem with the stable include directory list is that to change this list VA needs to rebuild its symbol database, which we try to avoid doing.

So when different configurations have different directory lists, either we need to tell you to rebuild your VA symbol database, which requires a restart, when you change the configuration you are working on, or merge all of the directory lists together. Normally merging them together doesn't seem to cause problems, but it is showing up here.

Is having both VCPKG paths in this list causing problems, or is it something that works for now?

The bug is still one that we are aware of, and recognise that it needs to be fixed, but currently it rarely comes up, so apparently VCPKG isn't that widely used by our users. Still, knowing it is also effecting you is important, since this helps us to prioritise which things to do next.
code_for_fun Posted - Jan 30 2022 : 07:18:35 AM
Adding vcpkg to include dirs helps, but it is a global setting. Vcpkg automatically changes internal dependencies depending on used triplet. E.g. there might be different headers with same name for static and dynamic CRT configuration, as well as differences on platform, that's already 4 combinations. Given that is very easy to make custom local packages for vcpkg VA should also take in count which triplet is in use and adjust to use correct location.
E.g. in default intellisense if you change platform it automatically updates the path to x86 or x64 packages, with current workaround user need manually to update VA settings. Also after trying different things project settings set both x86 and x64 paths which doesn't seem to correct:



Given that vcpkg is practically an official Visual Studio package manager it should be prioritized to work as expected.
feline Posted - Jan 10 2022 : 08:16:34 AM
This is still a bug report we are looking to fix, but unfortunately I don't currently have an estimate for when this will be looked at.

Thank you for the work around. Does adding the vcpkg directory to VA's Include Directories not do enough on its own? This was enough based on my tests when I put in the bug report.
asitrela Posted - Jan 08 2022 : 04:37:03 AM
I have no idea if this is still actual but I found a workaround for at least "in-code" autocomplete. If you click Extensions > VAssistX > Tools > Reload Solution then the *already-included* files are parsed, and function name etc. suggestions work. Anyway, we are looking forward to the fix for include autocomplete. :)
feline Posted - Jul 22 2020 : 2:45:36 PM
It looks like a change inside Visual Studio its self broke how we pick up the directories for vcpkg, I have put in a bug report for this:

case=142493

for now, manually adding the directory to the solution include directories should fix the problem.
feline Posted - Jul 21 2020 : 11:31:03 AM
Something is going wrong here, I am looking into it. For now, as a temporary work around, can you please go into your project settings, right click on the project node in Solution Explorer, and add the base directory that vcpkg is using for your libraries to the setting:

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

this should be the directory:

\\vcpkg\installed\x86-windows\include

where the first part will be the install path you have used for vcpkg. VA will pick up the required include directories from this setting.
SimonR_ Posted - Jul 20 2020 : 1:38:17 PM
Yes, I used the vcpkg to download the libraries. I've tried the global integration and the integration via NuGet, but VA doesn't work properly. The program itself compiles and runs fine. It worked one time, but not anymore. Also reinstalled Visual Studio, didn't help either.
feline Posted - Jul 20 2020 : 12:18:50 PM
From our release notes, VA has been handling the include directories for vcpkg directories for some years now. Setting up a test case to see if I can reproduce this problem here.
feline Posted - Jul 20 2020 : 07:37:52 AM
Can you explain what you mean by vcpkg? Have you installed boost via some form of package manager? Perhaps NuGet? If so, what method have you used?

Have you restarted the IDE since installing the boost package? I am wondering if VA has picked up the extra include directories yet? It sounds like it hasn't, but I am not sure why.

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