| T O P I C R E V I E W |
| .oisyn |
Posted - Jan 27 2006 : 12:47:17 PM
Hi,
I'm a gamedeveloper and we have a very large codebase with different branches. The main branch consists of a fairly large library, and every game shipped with this library has it's own branch of the library. This means a lot of duplicate symbols and files, but with different filepaths. I work in the different branches at the same time (using multiple instances of visual studio), and I find that visual assist has a hard time selecting the right file or symbol when issueing a "goto symbol" command.
The fact that we use an alternative build system doesn't help either, because the VC++ projects are makefile projects, so there's no way for visual assist to query the additional include paths for that project. Usually an "open header" command after placing the text editor cursor on an #include directive opens up the wrong header file or simply none at all. To fix this I have to add the respective directories to visual assist's options, but that obviously is a global option so it doesn't work well with the different branches.
I was wondering if there is a way to use seperate versions of the visual assist symbol database and/or settings, either bound to solution files or using environment variables or something similar (spawning different visual studio's with different environment variables isn't a problem as I'm doing that already anyway for the different branches).
If there isn't, I'd like to make it a feature request, and it'll make me and my coworkers very happy :) |
| 9 L A T E S T R E P L I E S (Newest First) |
| .oisyn |
Posted - Feb 02 2006 : 11:59:41 AM
quote:
Can we assume you are using the Unreal Engine?
No, we are engine developers ourselves :) (upcoming game: Tomb Raider Legend for PC/xbox/xbox360/PS2/PSP)
quote:
Try adding a new dummy project to each of your solutions so that you can set Additional Include Directories
Aaah now I understand. Nice trick. But the "parse all headers on project open" works perfectly. I disabled that option a year ago because it simply took to long when opening a huge project, but the current version of VA is a lot faster.
Thanks for your trouble. |
| sean |
Posted - Feb 02 2006 : 02:11:06 AM
Try adding a new dummy project to each of your solutions so that you can set Additional Include Directories. Create a different project for each of your solutions so that each new project points to the branch that the makefile in the sibling project is using. Also remove the directories from the VA options dlg since you want per solution directory lists.
In the solution explorer with a makefile project, you are able to add all of your source to the project sub-tree. Is your source available that way, or is the project empty from that perspective?
|
| support |
Posted - Feb 01 2006 : 11:20:12 PM
Another thing we recommend...
Eliminate the directories from the VA X options dialog, leave Platform=Win32, and add your directories to:
project properties|c/c++|General|Additional include paths |
| support |
Posted - Feb 01 2006 : 10:22:47 PM
We recommend keeping "Parse all headers..." enabled.
We recommend you disable "Guess contents if unknown" on "Text Editor|Listboxes" since you have so many similarly-named symbols.
Adding files to a project should not require restart of the IDE.
As you have discovered, VA X expects different sources to be associated with different projects. Your external makefile, and hence limited setting of IDE options and Project|Settings, make it that much more difficult.
We'll think some more about an elegant solution.
Can we assume you are using the Unreal Engine? |
| feline |
Posted - Feb 01 2006 : 5:28:09 PM
the status bar not clearing its self is unfortunately a known bug, and we have already tried to fix it once before. the IDE does not know VA is there, and thinks it has the status bar all to its self, so sneaking past it can be tricky.
the best way to check if VA has finished or not is to open the OFIW dialog. if it lists files then parsing has finished, while if it is empty and the title bar says "parsing..." then it has not yet finished.
depending on the size of the directory tree's involved you may find it fairly quick and easy to setup the additional include directories, etc, for your projects. you are not interested in a perfect setup that will actually compile. instead this is simply about giving VA enough information for it to find the correct files for you.
as for the dummy project, let me try to explain.
assume you have a tiny library made from the files:
C:\\feline\\src\\chocolate.cpp
C:\\feline\\src\\chocolate.h
in the IDE add a new project to the solution called "chocolate" and add these files to the project. since these library files are now part of the solution VA will know about them (this may require restarting the IDE, but hopefully not). since you have not compiling in the IDE the extra project does not matter. its only role is to help VA.
the down side is having it in the solution explorer, but if you give it a sensible name, perhaps "z_for_VA" so it is at the bottom of the list, out of the way, this should not be to big a problem.
of course if your experiences of VA not respecting project boundaries continue then this will not help as much as i would like. i am hoping this problem is tied to VA not knowing where to look for the files in the first place.
this is not a perfect solution, but you have a slightly uncommon situation. |
| .oisyn |
Posted - Jan 31 2006 : 06:45:39 AM
You know what, you're right, it doesn't take that long :). Although when parsing it seems to stop suddenly, while the status bar still shows "Parsing bla.h". But it's not using any cpu time anymore. Is this to spec, is it finished parsing?
And yes, we use a lot of macros as we're compiling for PC, Xbox, Xbox 360, PS2 and PS3, so there's a lot of conditionally compiled code for the different platforms.
Anyway, I think the major problem is not having regular VC++ project files, but makefile projects. Because the files are built using some kind of makefile tool, we don't have to supply for additional include directories in the IDE. VS itself doesn't know where my files are (right-click and "Open document bla.h", when hovering over an include directive, doesn't work as it only searches the standard include directories such as the platform sdk) |
| feline |
Posted - Jan 30 2006 : 4:24:40 PM
i suspect VA is trying to find the correct files, since this is what is normally required. this header file you are opening, is it a member of any of the projects in the current branch? i am wondering how to try and setup a small test of this effect. this makes it easier when trying to verify a code change in VA.
as for the speed, i have seen VA handle far more files successfully, but i suspect my files are on average smaller. does your code base make heavy use of macro's? if so this might explain the slow down. |
| .oisyn |
Posted - Jan 30 2006 : 06:31:26 AM
I'm not exactly sure what you mean with the dummy project... But the different branches have different solutions and projects, and I'm not really experiencing that visual assist totally respect project boundaries. If I'm working with a particular class that's defined in a header that I've never opened before in that branch (but I have in another branch in a totally different visual studio session), Visual Assist tends to link to the file in the other branch, which is obviously not what I want, and in the worst case I end up editing the wrong file.
And now that I think of it, it might be worth mentioning that I disabled the "parse all header files on project open" option because it simply takes too long with our project files (to give an idea, our current game we're working on, which is only a few weeks from shipment, currently counts 1301 c++ files (about 50% of them being header files) and approximately 600.000 lines of code). |
| feline |
Posted - Jan 29 2006 : 2:32:15 PM
making the assumption that each game, so each instance of the IDE has a single solution with one or more projects inside of it, is it possible to add a new "dummy" project to these solutions?
i am picturing a project that holds the code for the specific library and branch that this solution uses. this gives VA a change to know which files you are actually referencing in a given version of the IDE.
i am not actually sure that this will do what you want, but it might. i will ask support about this one and see if they can suggest anything else. |
|
|
