|T O P I C R E V I E W
||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.
Using VAX "Add Include" feature to automatically include bar.h in foo.h results in the statement:
However, we would prefer the include statement to be
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)
||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.
||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.
||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.
||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
quote: to generalize the problem and to ease the setup.
"add an option which will make VA to add includes relatively to one of the include directories without using ".." in the include path."
||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 "foo.h" // i.e. not "../foo.h"
#include "dummy/bar.h" // i.e. not "bar.h"
||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?
||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). :-)
||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.