| Author |
 Topic  |
|
|
markgladding
New Member
Australia
3 Posts |
 Posted - Nov 01 2007 : 8:16:42 PM
|
The company that I contract to has a large C++ codebase, organized into approximately 150 projects. All include file paths are managed using the VC project's 'Additional Include Directories' property.
As you can imagine, our high-level, application-specific projects have many dependencies on lower level projects. For example it's not uncommon for a project to have 40-50 additional include paths.
What I would like VAX to do is to manage these paths for me. For example if I reference a class that belongs to a previously unreferenced project, it would ensure that the relevant include path was added to the referencing project.
Similarly if a dependency was completely removed, the include path could also be removed from the project.
If a class changes location, remapping all the include paths to refer to the new location would be very useful.
I believe that VAX already has the required information to implement this feature as I can always navigate to a header file from the #include statement using Alt-G, even from a class within a project that doesn't have the correct include paths setup.
If this feature could be implemented it would remove a very tedious aspect of C++ development.
Regards,
Mark Gladding.
|
Author of Text2Go, text to speech to your iPod. |
|
|
feline
Whole Tomato Software
United Kingdom
18950 Posts |
Posted - Nov 05 2007 : 09:01:32 AM
|
While this is an interesting idea, there are certain problems here.
Firstly VA does not currently track the current project in the IDE, so it would not know which project to update.
Assuming for the moment this was changed, what happens when the current cpp file is a member of more than one project? The IDE will quite happily let you do this.
Then you have the problem of different C++ include directories for different modes. One set for DEBUG mode, one set for RELEASE mode, and possibly several other sets as well. |
zen is the art of being at one with the two'ness |
 |
|
|
markgladding
New Member
Australia
3 Posts |
Posted - Nov 06 2007 : 5:11:05 PM
|
As this is a command that works on a VC project, perhaps you could introduce a project-based command. To execute one of these commands, the user would have to select a project within the Solution explorer.
The problem of different configurations and platforms is an interesting one. We don't have different paths for Debug/Release configurations but we do have different paths for Win32/WinCE platforms. A general solution would have to cater for differences between any configuration/platform combination.
I suggest that you would need to maintain separate information for each configuration/platform combination. You would then need to use the correct set of information to update the include paths for a single configuration/platform. The command could update the include paths for just the current configuration/platform or ideally it would cycle through each configuration/platform and update each in turn.
The benefit of maintaining separate sets of information for each configuration/platform would also be useful for other VAX commands. For instance, when navigating to an MFC class using Alt-G, if the current configuration/platform was taken into account, then VAX could navigate directly to the correct header (e.g. Win32 header when Win32 platform current or WinCE header when the WinCE platform is current) rather than displaying both headers in a menu and asking the user to select the correct one.
Now as most of the information would be common across all configurations/platforms, you would probably want to maintain a single set of common information and the differences for each individual configuration/platform.
It sounds like quite a bit of work to implement but I think it would be a really great feature.
|
Author of Text2Go, text to speech to your iPod. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18950 Posts |
Posted - Nov 07 2007 : 12:50:07 PM
|
Your reference to using different platforms got me thinking about duplicate file names. At first I was wondering about duplicates in different platforms, so that VA cannot tell from the class name alone which file to use, it needs to know which platform to look in.
This may or may not happen in reality, but duplicate file names within the solution are actually quite common. I have seen quite a few bug reports from different users where duplicate file names have been the cause of the problem. Shared files in VSS are one common source of duplicate file names.
As soon as this starts happening VA will see the new class name, but it will not know which header file it really comes from, and thus it will not know which project it comes from.
The edge cases just seem to keep on multiplying. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
VC++ Project include file management
