Intellisense remote "include" cache

[andrew.bentley]

Good morning,

We continuously run into issues with the directory management for the Intellisense “include” directories.

The most common situation we see is when a single solution is shared among multiple users. Remote cache directories appear to get re-mapped into the local cache location. For example, the remote directory “/usr/include” is added and cached, but after reopening the project the entry is replaced with the local directory “C:\Users\andrew.bentley\AppData\Local\…\usr\include”. Since each user has their own repository of application data, this cannot be effectively shared.

Can remote cache storage be managed with any more customization? I really like the fact that the files are cached automatically when a remote location is added, but I would like to:
1. Specify what directory those remote files are cached to. Sharing as part of the git repo would be acceptable.
2. Map the directories clearly. It seems right now that where the directories get mapped is somewhat non-deterministic (…\RemoteSourceCache\server-name-or-ip\0003\usr\include).
3. Keep the Intellisense include directories as part of a user-specific configuration instead of shared among users

I’m open to other ways of achieving this, we could just use a little more consistency. Or, if there’s something I’m missing, feel free to point it out!

Thanks,
Andrew

 

[support]

Hi,

No problem, we can help you.

It looks like you might be using the old-style VisualGDB projects (e.g. GNU Make-based) that have to store various cached information (e.g. cached include paths) in the VC++ project files (hence, causing inconvenience with sharing the settings). If this is the case, would it be an option for you to upgrade to CMake?

The VisualGDB’s advanced CMake Project Subsystem provides much better experience – it will dynamically compute the cached file paths (and refresh when if needed) and won’t store any non-portable settings in the project file. It will automatically edit CMakeLists.txt files for you, so you won’t need to spend time getting used to the CMake syntax. You can get a quick overview of this subsystem here. If also lets you to debug the CMake scripts themselves, so you can diagnose settings-related problems faster than with GNU Make.

If this is not an option, please let us know which VisualGDB version you are using. v5.3 and later should automatically use the $(LOCALAPPDATA) syntax instead of relative paths.

[andrew.bentley]

I appreciate you pointing that out. For our existing projects that conversion may be a tough sell. I will experiment with CMake though, as it seems to offer some advantages.

Thanks,
Andrew

[support]

Hi,

Yes, converting large projects could be a non-trivial endeavor, but it might save time long-term due to better integration with VisualGDB’s features. Ultimately we can help you get it to work with any project type you choose, just wanted to ensure you are aware of the advantages of the new CMake Project Subsystem.

As long as you are using VisualGDB 5.3 or later, please try modifying anything on the Makefile Settings page of VisualGDB and click “Apply”. VisualGDB should retest the toolchain and save the include paths using the $(LOCALAPPDATA) syntax.

[Author]

Posts