| Author |
 Topic  |
|
|
marovira
Junior Member
12 Posts |
 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. |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
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:
case=148685
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. |
zen is the art of being at one with the two'ness |
 |
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
Posted - Oct 06 2022 : 03:12:31 AM
|
Hi,
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)
|
C++/Qt developer |
|
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
Posted - Oct 13 2022 : 08:11:41 AM
|
| Do you have any timeline when this support for external headers could get into the release? |
C++/Qt developer |
|
|
|
Eddie_cz
New Member
Czech Republic
8 Posts |
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" |
|
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
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)
|
C++/Qt developer |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
marovira
Junior Member
12 Posts |
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. |
Edited by - marovira on Nov 11 2022 1:06:54 PM |
|
|
|
templar-von-midgard
Starting Member
Hungary
1 Posts |
Posted - Nov 11 2022 : 2:46:38 PM
|
A possible workaround for CMake users is putting
unset(CMAKE_INCLUDE_SYSTEM_FLAG_CXX)
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.
|
Edited by - templar-von-midgard on Nov 11 2022 2:47:05 PM |
|
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
Posted - Nov 14 2022 : 03:12:27 AM
|
@templar-von-midgard Thank you! That trick worked.
I also found and tried to do:
set(CMAKE_NO_SYSTEM_FROM_IMPORTED TRUE)
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!
[1] CMake docs https://cmake.org/cmake/help/latest/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html |
C++/Qt developer |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
Posted - Feb 12 2024 : 02:19:17 AM
|
Hi guys, is there any hope this will get fixed so that we don't need to use build system workarounds?
Will Visual Assist support the include paths that are external?
It's been more than a year now and today I checked released notes and still don't see this improved. |
C++/Qt developer |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Feb 12 2024 : 07:29:24 AM
|
Unfortunately no progress to report on this yet, but this is down as a high priority bug, and one we are hoping to get fixed soon.
Are you having problems that the work arounds aren't stable? Or are you running into this when creating / setting up a new project? |
zen is the art of being at one with the two'ness |
|
|
|
LukasT.dev
New Member
Slovakia
6 Posts |
Posted - Feb 14 2024 : 3:09:05 PM
|
Thanks feline,
Workaround seems to be working stable so far, but it is something I have to keep in mind every time I re-configure or recreate my CMake repos (I have dozen of them), so it is annoying.
|
C++/Qt developer |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Feb 15 2024 : 09:31:44 AM
|
| Thank you for the update, at least the fix is stable, that is good news. Having to keep on applying it isn't helpful, but hopefully not a constant problem. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Support external headers
