Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Add Include refactoring using absolut project path

You must be registered to post a reply.
Click here to register.

Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji

Forum code is on.
Html is off.

Check to subscribe to this topic.

T O P I C    R E V I E W
Luke1410 Posted - Sep 28 2009 : 09:24:45 AM

Would it be possible to tell the "Add Include" feature to generate the include statements using paths relative to the project root?

One of our code conventions in use defines that all include statements must be specified relative to the project root in order to not run into problems when header files are being moved.

file structure:

Using VAX "Add Include" feature to automatically include bar.h in foo.h results in the statement:
#include "bar.h"

However, we would prefer the include statement to be
#include "package/bar.h"

Quite convenient would be if VAX automatically guesses whether absolut or relative paths are to be used based on the already existing include statements in the header files as it does with guessing the correct path separator.

8   L A T E S T    R E P L I E S    (Newest First)
sean Posted - Sep 24 2018 : 2:31:20 PM
case=33851 is implemented in build 2291 -- see Add Include path on the Code Generation page of the VA Options dlg.
feline Posted - Jul 18 2011 : 1:14:05 PM
Apologies for the slow reply. There is a registry key setting for this, as explained in this FAQ entry:


If I understand correctly this should do what you want.
thethirdhalf Posted - Jul 13 2011 : 10:26:41 AM
I noticed that in the latest build (10.6.1850.0), it always includes relative paths in the add include option (it has done this for as long as I have used the option).

However, this couples the code to what should be a build system issue, which is indicative of a failure to properly configure the build. Relative and absolute paths to headers in code is really fragile. Our build system handles this seamlessly for us.

Is this option configurable? I haven't been able to find this out by searching. If I want to include 'Bar.h', I need it to show up as #include <Bar.h>, no matter where it is in the project.

accord Posted - Oct 14 2009 : 5:20:46 PM
I have put in a feature request to see what the developers make of it:


I suggested to
"add an option which will make VA to add includes relatively to one of the include directories without using ".." in the include path."
to generalize the problem and to ease the setup.
Luke1410 Posted - Oct 13 2009 : 5:02:32 PM
Yes, we've added "." as the first include directory in the "compiler additional include directory"-setting. Beside 3rd party include directories, that's the only project include directory in the list.

As far as I can see ur suggested implementation might do the trick for us.
An alternative way could be to specify an optional root folder in the registry.
Assuming that root folder being set to: "C:\\project":
#include "dummy/bar.h"
#include "foo.h" // i.e. not "../foo.h"
#include "dummy/bar.h" // i.e. not "bar.h"
accord Posted - Oct 13 2009 : 4:43:15 PM
Have you specified the project root as an include directory or as an additional include directory? Is this the only include directory that you use? (in addition to the 3rd party includes)
I'm wondering how this feature would be implemented. May be suitable to add an option which will make VA to add includes relatively to one of the include directories without using ".." in the include path.
Would this approach be appropriate for you?
Luke1410 Posted - Oct 01 2009 : 5:16:29 PM
Well I won't argue with you about the usefulness of this particular code convention. Looking at our 3rd party libraries we have in use shows at least one which follows this include convention too, however (namely FCollada).

I understand that this feature might not be of a broad application around VAX users, so I understand that time would be better spent on other issues.
However, in our case it would be more than sufficient to get VAX to always add includes with paths relative to the project root (maybe setable via a registry entry). :-)
accord Posted - Sep 28 2009 : 4:01:08 PM
I see your motivation behind this, but detecting something like this can be quite ambiguous. Consider the following: we have 3 includes, and every one is a relative path and also, each of the headers are in a different directory, so the relative path is necessary. In a case like this, we cannot decide which method to choose. Anyway, I think that this code convention is a little "odd", but this is only my personal opinion.

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