| Author |
 Topic  |
|
swinefeaster
Tomato Guru
310 Posts |
 Posted - Feb 23 2006 : 1:16:55 PM
|
is there any way in VAX to specify additional source directories to parse *relative* to the project or solution? can you use VS2005 $(xxx) macros in the VAX option pages...?
the reason i'm askin is that we've recently switched to splitting up the project into various dlls, so a lot of common code does not get automatically parsed. i mean, VAX finds out about it through the includes, but you can't the OFIW or FSIW dialogs (obviously).
what's the best way around this, without having to add all the header files for these dlls into the project itself?
keep in mind this has to be relative because if we work in a branch, the absolute path will change.
thanks
swine |
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Feb 23 2006 : 3:09:28 PM
|
now you have got me wondering how this works. i use a similar situation some of the time, multiple branches and code split into dll's. for me though each dll is a separate project in the same solution.
when i need to work in a different branch i check out a complete copy of the code to a different directory tree. so the main version is in the tree "CODE-MAIN", release 9 in the tree "CODE-Release-9", etc.
so the absolute paths of the files keep on changing, but the IDE (i have done this with both VS2003 and VS2005) handles it quite happily. so obviously the IDE must be somehow handling the changing absolute paths.
i suspect the easiest solution is to add a new project to your solution, drag the common code into this project, and then exclude the project from the build. the big question is how this will work with the branches. my experience suggests it will just work, and since the code is included in the solution VA will know about it. |
zen is the art of being at one with the two'ness |
 |
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Feb 24 2006 : 1:28:21 PM
|
thanks for the detailed reply... but:
1. I am still unclear as whether the VAX "Options | Projects | C++ Directories" pages accept $(xxx) macros. Do they?
2. I know I can add the project. But that's rather painful. That means Visual Studio will have to check its dependencies and parse the whole thing, etc etc. A nice little path option in VAX for this would be nice, maybe under the C++ Directories pages... I'm sure a lot of people would benefit from this, no?
Cheers,
swine |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Feb 25 2006 : 3:03:32 PM
|
point 1, i have just tested this using VS2003 and VA 1440, and it does work. i have set the system environment variable QTDIR to "C:\\qt\\live"
in IDE tools menu -> options -> projects -> VC++ directories -> include directories
i added $(QTDIR)\\include
this directory then shows up in VA's stable include directory list, but interestingly enough it is showing up as the actual directory path, so the environment variable has been expanded. the include files here are being picked up correctly.
my one concern with this approach is how prone Windows its self is to picking up the environment variables. i have been informed on several occasions that windows will pick up new environment variables without having to reboot the machine, but my experience is that a reboot has always been required *sigh*
so i don't know how responsive the OS will be, and VA will be reliant on the OS.
point 2, which IDE are you using? i have never seen any significant issues with VS2003 its self re-parsing code for intellisense, but both VA and VS2005 have a noticeable impact, although VS2005 has a massively bigger CPU load.
as for dependencies, i am under the impression that unless you set some dependencies between projects there will be nothing for the IDE to check.
i will ask support about this. the problem is that any such change would take a while to happen, assuming that it is agreed. in the mean time we need to try and find a good work around. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Feb 27 2006 : 12:55:30 PM
|
i am using VS2005.
i am not just talking about using environment variables, but more importantly the variables you can define in VS via property sheets. these should be expanded in that edit box and re-evaluated for each project, at least when the projects are loaded.
thanks! |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Feb 27 2006 : 4:28:59 PM
|
where do i look to find these property sheets? looking in the properties for the solution and the project (via solution explorer) is not throwing up anything obvious.
i know there are a number of pre-defined variables you can use in the IDE, but i don't think i am familiar with what you are talking about. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Feb 28 2006 : 5:47:24 PM
|
having read that page, and several related pages, i am not actually sure i am that much further forward.
are you thinking of placing a different .vsprops file in each directory tree? i am not even clear on how the IDE finds these files, or how this concept of inheritance is supposed to be applied. i got the impression values would be inherited from one .vsprops file into another .vsprops file. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 01 2006 : 12:39:22 PM
|
basically you can define a user macro, named say RootPath, that points to something like:
$(SolutionDir)Root
or
$(ProjectDir)SomeSubFolder\\Test
And then you can use RootPath in your project configuration. Such as in the Linker Input:
$(RootPath)MyUseless.lib
You can also tell it to define it in the build environment, and use it in batch files, such as:
copy c:\\Drivers\\*.exe %RootPath%\\Bin
Does that make any sense? So what I'm saying is that you should enable support for stuff like $(RootPath) in the VAX parse directories.
regards,
swine |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 01 2006 : 7:01:49 PM
|
that makes sense. i will run a couple of tests myself to see if VA picks these up, but i suspect it does not. have you tried this yourself?
the other thing i was wondering is does this actually provide a better / easier method than an environment variable for the code location? |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 01 2006 : 7:15:51 PM
|
i just assumed VAX didn't as, you didn't know what i was talking about ;).
yes it does provide a better way than just an environment variable, because it allows per-project and per-solution variables (rather than just one hard-coded system variable). |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 07 2006 : 4:37:17 PM
|
any thoughts on this? or was my suggestion crap?
;)
swine |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Mar 07 2006 : 8:17:52 PM
|
quote:
Originally posted by swinefeaster
is there any way in VAX to specify additional source directories to parse *relative* to the project or solution? can you use VS2005 $(xxx) macros in the VAX option pages...?
Sorry, no, you can't specify additional source directories relative to a project. And VA does not evaluate project $(xxx) macros.
quote:
the reason i'm askin is that we've recently switched to splitting up the project into various dlls, so a lot of common code does not get automatically parsed. i mean, VAX finds out about it through the includes, but you can't the OFIW or FSIW dialogs (obviously).
what's the best way around this, without having to add all the header files for these dlls into the project itself?
Adding to the source directories list wouldn't get files added to the OFIW or FSIW dlgs. It's more like additional include directories that you want.
By default, the FSIW dlg limits its list to symbols defined in the solution/workspace. Press Alt+S (to uncheck that default) and more of your external symbols should appear (the state of the checkbox is not saved between dlg instances).
The OFIW dlg has a similarly worded option but it doesn't work the way you would prefer/expect. Checking that option (off by default) will list any open files that are not part of the solution in the dlg.
I think that making the checkbox in the OFIW mean "search for and list all headers found via all the AdditionalIncludeDirectories settings in the solution" would address your situation, right?
|
Edited by - sean on Mar 07 2006 8:22:31 PM |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 08 2006 : 6:02:06 PM
|
Yes, that would address it --- though only if there was a way to specify project relative folders.
And it doesn't help if I have to clobber the whole FSIW dialog with all the mfc includes and source just to get to *my* shared symbols...
:( |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Mar 09 2006 : 12:22:46 AM
|
quote:
Originally posted by swinefeaster
Yes, that would address it --- though only if there was a way to specify project relative folders.
Aren't you already using project relative folders? In your first post you wrote "VAX finds out about it through the includes" - and the directories those includes are in must be specified via project AdditionalIncludeDirectories. If that is the case, then VA is already reading your project relative folders. Or are the project AdditionalIncludeDirs absolute?
quote:
And it doesn't help if I have to clobber the whole FSIW dialog with all the mfc includes and source just to get to *my* shared symbols...
I'm not following the whole picture.
You used to have a monolithic project that has been split up into various dlls. So that means there are now multiple projects, one for each dll (per branch)?
Is there a reason there isn't a solution that contains all the projects on the branch that are related?
|
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 09 2006 : 12:56:39 PM
|
| AdditionalIncludeDirs are absolute as far as I can tell. Yes, VAX is getting to my folders, but by reading the #include statements, etc, but then the symbols don't get colored correctly in autocomplete lists, and I never see them in the FSIW or OFIW dialogs. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Mar 10 2006 : 03:17:07 AM
|
quote:
Originally posted by swinefeaster
AdditionalIncludeDirs are absolute as far as I can tell.
So your projects use absolute paths, but you want VA to use relative paths (and ignore the absolute paths)?
quote:
the symbols don't get colored correctly in autocomplete lists
If they are colored at all, then VA must have found the #includes. The method by which it finds includes has no bearing on how symbols are colored (unless it can't find them at all, in which case the symbols will be uncolored and possibly underlined). So if they are colored in any way, changing paths and directories won't change the coloring - that sounds like a parser bug.
Going back to the first message of the thread:
quote:
what's the best way around this, without having to add all the header files for these dlls into the project itself?
The best way around this is to add all the projects you are interested in to a single solution. Don't modify any of the projects or the VA options.
|
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 10 2006 : 12:51:52 PM
|
| sean, i guess you are missing the point entirely. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 10 2006 : 2:31:42 PM
|
re-reading the second half of this thread, i am not sure i am following it either to be honest.
going back to the very first post in this thread, your code structure sounds like one i work on. we have a single solution with about 83 projects inside of it. this builds one exe and all of the dll's that this exe pulls in and loads.
the concept of splitting the code into separate dll's seems perfectly sensible. to give a concrete example we have a database dll and a common components dll. other parts of the code base use classes that are exported from these "base" dll's.
in this code base each version contains ALL of the code, and thus all dll's. this is done via cvs and tagging, so we are not storing duplicate code.
how are you structuring your code and solutions? if branch1 and branch2 are checked out to:
C:\\branch1\C:\\branch2\
how do you compile one or the other? if the solution does not contain the project for your dll, how will it know to recompile this dll when you check out the code? i can understand the linker picking up the dll from a relative location, but where does this dll come from? if it comes from code (surely it must, you want VA to find this code) then surely the code is in the branch1 or branch2 directory tree, and thus it has to be compiled to produce the dll.
do you see what i am asking / saying? if we can all understand what is going on here it should help. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 10 2006 : 7:55:20 PM
|
ok let me explain! 
we have two solutions, one called SharePool (it's got all the common stuff in dlls), and one called PcApp for example (it's builds the exe).
directory structure is as follows:
c:\\Branch1\\SharePool
c:\\Branch1\\PcApp
c:\\Branch2\\SharePool
c:\\Branch2\\PcApp
so... PcApp links to SharePool in its branch, relatively. actually we define a user macro called $(SharePoolDir) which in PcApp is "$(SolutionDir)..\\SharePool\\" and thus becomes "c:\\Branch1\\PcApp\\..\\SharePool".
most developers wont need to build SharePool at all, as the compiled dll binaries are shared on a network folder, and we got custom build steps to copy them over for the correct branch ;).
i don't wanna just include all those headers from SharePool in PcApp, as i would have to manually take out all the cpps, and then maintain any changes to synchronize it with the SharePool solution.
vc8 has no problem finding the headers. i can even do autocomplete with VAX (or is it being done by vc8?) but those symbols in SharePool are not colored in the autocomplete dropdown box, and most importantly, these symbols cannot be found in the OFIW and FSIW dialogs, as they are not in the workspace.
it would be great if i could add extra solution-relative directories (or using vc8 user macros) so that these symbols would appear. again i don't want to add them to the solution, as that would make vc8 think too much...
cheers,
swine |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 11 2006 : 11:40:10 AM
|
now i understand. at this point we need to focus on finding you a work around, since any change to VA will take time to appear.
i am making the wild assumption that you have a solution for SharePool, so you in fact have:
C:\\Branch1\\SharePool\\SharePool.vcproj
C:\\Branch2\\SharePool\\SharePool.vcproj
these solutions are used to actually compile SharePool, so by definition they must actually be kept up to date, or else SharePool would stop building.
have you considered simply adding the relevant SharePool.vcproj to PcApp as a project, and then removing all build dependencies? this does still leave you with the problem of VS2005 getting all excited though, which can be bad if you are using C++.
what have you set:
VA Options -> text editor -> listboxes -> get content from default intellisense
to? the fact that you are getting intellisense on this code is interesting. does alt-g allow you to jump into the SharePool directory tree? |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 13 2006 : 1:48:18 PM
|
Yes, I have a project for SharePool. I usally build it in another instance of vc8, but only if i have to.
Yes, alt-g does allow me to jump into SharePool. And after the file opens, it appears in the OFIW and FSIW dialogs (even though its not in the workspace).
Get from default intellisense is OFF.
I don't really want to add SharePool to the solution. That would definitely get vc all excited, and especially now that they totally screwed up the function of F7 --- SharePool would also build each time I pressed F7, even with no dependencies.
Thanks,
swine
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 13 2006 : 4:26:56 PM
|
*ouch* i was not aware that VS2005 had broken F7. have you looked into IDE build menu -> configuration manager ?
i have often used this in VS2003 to trim down the build size, but i have not really used it in VS2005. hopefully unticking SharePool in here will stop the IDE from ever building it.
personally i am confused by alt-g working. does alt-g always jump into the correct SharePool directory tree?
at a very basic level what works and what is broken? does VA offer suggestions on the classes from SharePool? are they coloured as types? |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 13 2006 : 5:00:03 PM
|
well there's no concept of Active Project in .net. in vc6 you just set the active project and that builds, along with all its dependencies. in vc8, you can set up a startup project, but that's different. F7 still always builds the whole solution. the only way of doing one project is to right click on it and go Build --- using the mouse just sucks.
yes, alt_g always jumps to the correct tree... |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 13 2006 : 5:08:33 PM
|
| ok i just sent you a video of this. |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 17 2006 : 9:10:50 PM
|
| ok i can no longer alt+g into the SharePool code now that i updated to 1444. this is becoming more of a problem :(. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 20 2006 : 5:47:13 PM
|
i have the movie, apologies for the delay, i have been down with the flu *sigh*
these movies are both helpful and very hard to follow, since you know what you are doing, but i have to guess what you are doing and what to follow attention to.
for OFIW it *looked* like a SharePool file was listed as long as it was open, but only if it was open. is that correct? if so then this explains what is going on, and in fact this is not actually related to the directory structure layout at all.
the bigger mystery to me is that VA seems to know all about these SharePool classes, so it seems to have found the code. but how has it found the code?
can you post the information you get from:
VA Options -> About -> Copy Info
this may not help, but it is a start. somehow, from somewhere, VA is picking up the SharePool code. once we know how and where this should help.
as for F7, from the following to links:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=3038
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_072804a.aspx
you probably want to remap F7 to "Build.BuildOnlyProject" in IDE tools menu -> options -> environment -> keyboard
this is what Microsoft say does this, but you may want to check out "Build.BuildSelection" |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 21 2006 : 6:10:17 PM
|
i have just checked, VS2003 and VA 1440 the OFIW dialog lists all open files. retesting this in VS2005 with VA 1444 and any open *.txt files or *.cpp files that are not part of the solution are listed in OFIW.
so this still works for me, so i would expect it to work for you.
i am expecting VA to parse your projects additional include directories, presuming they are actually set using the good old right click on project in solution explorer -> properties method. you appear to be using an environment variable here to indicate the correct location for the SharePool source code. is this true?
do you know which version of VA you were using before? 1440 does not seem to contain much in the way of fixes above and beyond 1440, so you may find moving back to 1440 helps. however by the same logic 1444 should not have broken things for you. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 21 2006 : 6:36:17 PM
|
sorry i was unclear --- 1444 did not change the workings of the OFIW or FSIW dialogs, but rather broke the autocomplete suggestions for sharepool symbols (the uncolored symbols like i showed you in the video).
yes, i am using the "good ol' right click on project" method. but no it is not an enviroment variable, but a vs2005 officially-accepted user macro ;), which my whole point is that you guys should support it!
cheers,
matus |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Mar 22 2006 : 3:30:19 PM
|
i agree these macro's should be supported. *goes and scans the entire thread*
i never did work out how you are supposed to specify these variables in files. the link you posted did not get me very far. can you post the content of a basic .vsprops file to this thread? i can then just take an existing one, and try to make it work here.
i am getting confused by the number of points we are dealing with at once in this thread, so if you don't mind lets try to do this one small step at a time.
if i can produce a small sample project, where a .vsprops file is used to define an environment variable - just like your $(SharePoolDir) - then we have a nice clear example. this bypasses the whole question of relative directories, and lets us focus on what we want VA to do. |
zen is the art of being at one with the two'ness |
|
|
|
swinefeaster
Tomato Guru
310 Posts |
Posted - Mar 22 2006 : 5:13:04 PM
|
ok i just send you another video *gulp* of how you can set up a user macro and all that. let me know if you need more info on anything.
swine |
|
|
|
Topic |
|
Project-Relative Additional Parse Directories
