| Author |
 Topic  |
|
|
udoeb
Junior Member
12 Posts |
 Posted - Nov 16 2017 : 3:20:18 PM
|
Hi,
I use VA for all my C++ development on Windows (VS2015). Now I'm working on C++ projects for embedded systems. I use VisualGDB plugin (visualgdb.com) for the build with GNU gcc compiler. This works great except for VA Intellisense parsing. The problem is that VA is not aware of the preprocessor symbols (such as __GNUCC__) that gcc defines implicitly. Without these symbols, VA cannot interpret header files correctly. There is a similar problem with include paths.
My question is: Is there a way to configure VA with additional #defines and include paths it should consider when it parses files?
For example, an external text file (xml, json, ini, or similar format) that VA reads in would be great because such a file can be generated from the gcc project settings easily.
Thanks
Udo
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 16 2017 : 3:34:39 PM
|
Yes there is, but it may take a bit of configuring to get this working correctly in your situation. If you make a new text file called "va_stdafx.h" and place it in the same directory as your .SLN or .VCXPROJ file, VA will automatically find and parse this file before starting to parse your solution. This is explained here:
https://support.wholetomato.com/default.asp?W302
Just make sure that the file ends with a blank line.
One limitation of this though, this file is only read when VA does a rebuild of its symbol database, normally by pressing the button:
VA Options -> Performance -> Rebuild symbol databases
so if the content of the file is modified by your gcc settings, VA may not register this change.
For the directories to scan, can you just add these directly to the project, assuming you have generated a VS2015 solution and project? |
zen is the art of being at one with the two'ness |
 |
|
|
udoeb
Junior Member
12 Posts |
Posted - Nov 16 2017 : 3:54:32 PM
|
Thanks for the quick reply. I will try the va_stdafx.h approach and report back.
As for the include directories: Unfortunately VisualGDB uses a custom project type. There is an include path setting but VA seems not to be aware of it. It ignores the paths set therein and uses the standard VS paths which include MS header files and not gcc files of course. Also gcc uses some built-in include paths which I would need to specify for VA explicitly.
Udo
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 16 2017 : 3:57:52 PM
|
You can tell VA to use a custom set of directories to scan, as explained here:
https://support.wholetomato.com/default.asp?W652
the only obvious problem with this is if you are working on several different VisualGDB projects, or switch between VisualGDB and Microsoft projects, so want VA to be using project specific directories. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Nov 18 2017 : 4:23:31 PM
|
Specifying the symbols via va_stdafx.h does work. Thanks for the tip.
Specifying gcc-specific include paths via Custom platform settings does work as well. However, switching between platforms and clicking Rebuild manually every time is a bit annoying (I have to switch between MS and VisualGDB projects quite often). It would be great if VA would allow to add a new platform (such as VisualGDB) including path settings, and then would automatically select the platform specific settings based on the current project's platform (which is VisualGDB in my case).
Udo
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 20 2017 : 07:25:40 AM
|
Would you be able to send me a very simple VisualGDB project, just a couple of code files, that I can try testing here? It looks like I can download a demo version of VisualGDB easily enough to try, but I want to make sure I am testing the right sort of solution.
I am just wondering if it is possible to add include directories to the VisualGDB project in a format that VA will understand, which would solve most of these problems, since VA would then know what directories to use for each solution.
If so, please submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Nov 24 2017 : 3:37:38 PM
|
I submitted a sample project via the support form.
Udo
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 29 2017 : 10:29:05 AM
|
Thank you for the sample project, and apologies for the slow reply:
case 112551
We are looking to improve support for VisualGDB projects, and your sample project and notes have done a very good job of explaining what we need to do, and where the required information is coming from, information which I have added to the case:
case=94717
Do the system include directories for your existing VisualGDB projects change very often, or are these mostly static once set up and configured?
If, for a given VisualGDB project these are basically stable, then the following should work. Set the VA platform to Custom:
https://docs.wholetomato.com/default.asp?W213
and delete the standard Win32 library directories from this platform list. Then add the VisualGDB system include directories to:
Project properties -> C/C++ -> Additional Include Directories
which are already being picked up correctly by VA.
The main problems with this approach is that VA won't know which symbols are static and which aren't, so won't be able so show symbols from your stable include directories in italic. Also, you will need to add the Win32 stable include directories to your Win32 project settings in the same way, unless you want to keep on changing the platform back and forward. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Nov 29 2017 : 11:23:45 AM
|
Thanks for your reply. This sounds good. VisualGDB is a great tool and if one can combine it with VA this would be even better.
Potentially system include directories for VisualGDB projects change often when you are working on several embedded projects in parallel. Typically, each project uses a different gcc tool chain. So if VA could fetch the include paths from project settings, or from a file which is located next to the .vcxproj file, this would be much easier manageable.
I did try the Custom platform approach already (with VS2015) but without success. I can try it again with VS2017 and report back what exactly is not working, but the above approach would be a better solution. No problem for me to wait until it's available.
Udo
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 29 2017 : 3:13:45 PM
|
Now I know to watch the logging, for when Visual GDB is passing the system include directories to the IDE, I have made an "interesting" discovery. These directories are not passed on solution load, they are actually only passed when first opening a .cpp file.
Also, there is no sign of them anywhere in any file in the solution directory, at least not in your test solution. If I delete the debug and temporary directories that the IDE creates, the paths are nowhere to be found, but they are still passed to the IDE, and show up in the logging.
So, it looks like we would need to wait for Visual GDB to tell us the paths for a given solution, and since they are somewhat fluid, keeping the results as stable include directory information won't make much sense.
Once you have set up an embedded project, are the directories for this particular project stable? Or do they still change, fairly regularly, with time? I am wondering about using a script to configure the IDE for a given Visual GDB project, and then load the IDE with this project after the matching changes have been made. It risks being fragile, but it might be worth investigating. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Nov 30 2017 : 4:14:48 PM
|
Interesting findings...
I think it works as follows: In the .vcxproj file VGDB keeps a reference on the toolchain used for the given project. The tags <ToolchainID> and <ToolchainVersion> are pointers into a global directory where VGDB installs toolchains. In my case this is:
c:\SysGCC\arm-eabi
In this directory there is toolchain.xml which contains a matching <ToolchainID> tag. There is also IntelliSense.props which has the specific system include paths (and defines). But note that some path components depend on compiler options such as 'FloatABI'.
So to access the sys include path, you would need to resolve VGDB's <ToolchainID> reference and also need to emulate processing of compiler options. Does not sound like a good approach because it deals with VGDB internals too much.
Some ideas:
- VGDB could provide a variable in the IDE which holds the sys include path, or is this called a macro? I mean one of those $(IncludePath) variables. Can VA access such a variable at runtime?
Probably, you would need to talk to the VGDB people. According to my experience they are very responsive and open to new ideas. You can try their forum:
https://sysprogs.com/w/forums/forum/visualgdb/
- Could we establish such a variable via a .props file which we add to the .vcxproj? Less elegant because one would need to maintain the path in the .props manually.
Udo
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 01 2017 : 08:09:11 AM
|
I tracked down the "nxp_lpc.xml" file in the same directory as the .SLN file in the sample solution, which seems to contain the references that Visual GDB is using to work out the directories. In theory VA will be able to pick up the directories once they are passed to the IDE, we will just have to wait for you to open at least one .cpp file before we can start parsing any files in these directories, since we won't know where they are until then.
If you know the directories that you will need for a given VGDB project, then you can manually add these directories to the IDE settings, which VA will then pick up as normal when the project is loaded by the IDE. Not quite the same, but this is something you can set up and get working now, without any further changes to either VA or VGDB.
But I don't know if this approach is reasonable for you or not. It sounds reasonable, since if the directories only have to be changed occasionally, this is not too much of a problem, but it is still a work around. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Dec 03 2017 : 2:49:47 PM
|
Adding the sys include path to the compiler's include path in project properties is not a good idea because this changes the way the _compiler_ (not Intellisense) looks for sys include files. During compilation one should rely on gcc's built-in search path.
I tried again the approach you mentioned above and that's described here: https://docs.wholetomato.com/default.asp?W213
Switching to platform Custom and defining gcc's sys path under Custom does work. If I keep the platform set to Custom then VA is able to locate gcc's .h files. This basically solves my actual problem.
The only thing that's a bit annoying is that I have to switch back and forth between Custom and x64/Win32 when I work on
embedded projects and Windows projects in parallel. Because VDGB uses a distinct platform called "VisualGDB" I have the following suggestion/question:
Couldn't be VA's custom platform management made a bit more flexible and let me define my own custom platform, name it "VisualGDB" and let me define a search path for it. Then VA automatically picks that platform's settings when the current project's platform is "VisualGDB", and it automatically switches back to x64/Win32 when the current project is a Windows project. In other words, VA's platform selection automatically follows the plaform of the current project (or solution). For x64 and Win32 this seems to be working already.
This would be good solution for custom platforms like VisualGDB.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 04 2017 : 05:56:57 AM
|
It looks like I mis-understood something about how Visual GDB works. I thought that Visual GDB, and thus Clang were getting the include paths from the location of GCC, and the compiler settings, not from the generated .VCXPROJ file that the IDE is reading and working with.
This is why I thought it would be safe to add the system include paths to the .VCXPROJ file, since I was not expecting Visual GDB to be reading this, and passing the extra directories through to GCC. Is this wrong? |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Dec 04 2017 : 07:09:07 AM
|
There are two separate search paths:
a) Project specific include path (typically relative to the project dir). This path is specified in the .vcxproj and passed to GCC as a set of -I options. In my sample project this path is "..\inc"
b) GCC's system include path (typically absolute paths). This is not specified anywhere but built into GCC itself.
The issue is about b). How can VA know the path b)?
With the solution I proposed above I would specify b) in VA's Custom (or better "VisualGDB") platform settings. The issue that remains is automatic switching between platforms depending on the current project (or solution).
There are even better (more comfortable) approaches, such as the dynamically created path variable in the IDE, but these would require closer interoperation between VA and VGDB which requires a discussion with the VGDB developers, I think.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 04 2017 : 08:53:12 AM
|
This makes sense, I did not properly understand what was happening with the include directory settings here. I have put in a feature request for using a specific platform and VA symbol database location when opening a Visual GDB format solution.
case=112732
One limitation with this, compared to picking up the directories when Visual GDB passes them in, is that the Visual GDB platform will need to be manually updated when the Visual GDB system include directories are changed, since VA won't be picking up and setting these directories its self.
For now, is loading the IDE and the matching solution via a script an option?
I am thinking of a script that edits the registry keys VA uses, to tell VA to use the Visual GDB platform and VA database path when loading a Visual GDB project, or the Win32 platform and the Win32 VA database path when loading a Windows project. Creating a custom platform is explained here:
https://support.wholetomato.com/default.asp?W652
and setting the VA database path is explained here:
https://support.wholetomato.com/default.asp?W332
but the platform would still need to be set for each IDE load. |
zen is the art of being at one with the two'ness |
|
|
|
udoeb
Junior Member
12 Posts |
Posted - Dec 04 2017 : 09:48:11 AM
|
Okay, using a script that patches HKCU\Software\Whole Tomato\UserDataDir (or sets an environment variable which is part of this path) and then launches VS, is an alternative solution to the manual platform switching I'm currently doing. But it's still a workaround. Having VA switch platforms automatically would be great. Thanks for filing a feature request.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 04 2017 : 4:55:29 PM
|
| Definitely just a work around, but a fairly specific and limited one, so hopefully worth the fuss for you. It does have the benefit of being something you can set up and get working now, without waiting on any changes to VA. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
VA with non MS build
