|T O P I C R E V I E W
||Posted - Sep 28 2022 : 7:40:07 PM
In Visual Studio 2017 version 15.6, the /external switch was introduced to allow headers to have separate compiler settings from your own code. CMake version 3.24 introduced support for this, so any headers included from libraries that are linked against an executable are now included via "/external:I" and therefore no longer appear in the "Additional Include Directories" field of the project properties. This is causing Visual Assist to fail generating suggestions for headers when typing "#include ...". Would it be possible to add support for this?
To reproduce, do the following:
1. Create a new empty C++ project.
2. Add a new C++ file called main.cpp
3. In the directory containing this file, create a new folder called "extern" and inside create a new file called "foo.hpp"
4. In Visual Studio, right-click the project and select Properties > C/C++ > Command Line.
5. Under Additional Options, enter: /external:I <path-to-extern-folder>
6. Click apply, then OK.
7. Open main.cpp, and begin typing: #include <foo.. See that no suggestions are shown.
It is worth noting that Visual Assist is able to offer completions on the contents of the header once it has been included, but it cannot offer suggestions while typing the include directive.
|10 L A T E S T R E P L I E S (Newest First)
||Posted - Nov 14 2022 : 10:53:55 AM
Thank you both for the possible work arounds, this is likely to be very helpful, until we get /external support added to VA.
||Posted - Nov 14 2022 : 03:12:27 AM
@templar-von-midgard Thank you! That trick worked.
I also found and tried to do:
and that moved the include dirs back to "Additional Include Directories" in MSVC IDE for targets.
Unfortunately our project already depends on CMake 3.22 so downgrading wasn't the choice, thanks marovira!
 CMake docs https://cmake.org/cmake/help/latest/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
||Posted - Nov 11 2022 : 2:46:38 PM
A possible workaround for CMake users is putting
right after the project call in the toplevel CMakeLists.txt. Though, it shall be noted, that this just happens to work currently, because of how the SYSTEM includes are implemented on the Visual Studio generators.
I haven't bothered checking whether this works in Open Folder (ie Ninja generator), or on other platforms.
||Posted - Nov 11 2022 : 1:02:39 PM
The inclusion through the /external switch is triggered automatically whenever you link a library using target_link_libraries. There are two "workarounds" to this:
1. Have the library be part of the build. This can be done through FetchContent or by having the source code be added directly through add_subdirectory
2. Set the include paths manually using target_include_directories.
As you might expect, option 1 isn't always viable as not all libraries allow compilation from source. The second option involves manually handling all the linking with a specific library, since you'd be bypassing the preferred target_link_libraries. This could cause complications with more complex libraries that would otherwise be avoided.
Alternatively one could downgrade CMake, though looking at the release notes, it seems this has been supported since 3.22 (released in July). This may not be a viable alternative depending on the situation.
||Posted - Nov 11 2022 : 12:46:09 PM
Unfortunately no update yet, but I have just increased the priority on this. The fact that your dependencies are regularly changing complicates matters, since it does indeed make the obvious work arounds a lot harder.
Is it an option to tell CMake to add these dependencies without making them external header directories? This assumes you are not relying on them being compiled with different settings, which as I understand it is why the setting exists.
||Posted - Nov 09 2022 : 10:09:14 AM
Hi, any update on this feature request?
My experience using Visual Assist in the CMake project with external headers is very poor. I can't navigate to the headers easily and the workaround provided does not work for me since
we update our dependencies regularly and it is a lot of paths to maintain (CMake + conan packages)
||Posted - Oct 13 2022 : 10:59:47 AM
We also have issues with external headers, also keep in mind that in clang-cl msvc env, external libs are added in additional options as -imsvc "path_to_external"
||Posted - Oct 13 2022 : 08:11:41 AM
Do you have any timeline when this support for external headers could get into the release?
||Posted - Oct 06 2022 : 03:12:31 AM
I have the same issue. The problem is that the paths for includes are changed every week in our project, since we manage our codebase in multiple repositories as separate C++ libs.
So the workaround is kinda working but it is dauting task to update list of include paths all the time.
It would be great if it would work out-of-the-box and /external:I paths would be supported by Visual Assist. The list on our project is long, we have 74 paths defined as /external:I (conan+cmake does that now)
||Posted - Sep 29 2022 : 10:54:42 AM
Thank you for the very clear explanation and description of how to reproduce this problem. I am seeing the same problem here:
For VA understanding the header file, this is because VA parses any file you open, so if you open the included file in the editor VA will parse it, and then remember the details. Before this has happened, VA doesn't actually know about the file or its contents, at least for me.
Interestingly, VS2019 doesn't know about these files either, but VS2022 does.
Definitely something we need to be aware of if this is the new default behaviour of CMake.
If you don't have to many of these directories then you might want to use VA's custom include directory list as a work around for this setting not being picked up by VA. To do this go to:
VA Options -> C/C++ Directories
here, by default, the platform pull down list at the top of the window is "Project defined", which is missing these extra include directories.
You can use the toolbar buttons to copy this default list, and then change the platform to "Custom", and paste in the default list to use as a start point. You can now add any extra directories you want VA to be aware of, which will be the ones added via this command line switch.
Not ideal, but hopefully a useful work around for now.