consolidating all libraries (user and VS C++ infrastructure ones)
I decided to get adventurous and move my 3 project and template directories from C to D.
D . Libraries . Documents . Visual Studio . Projects. Templates....etc.
However, when I compile, it still puts the obj and exe files in the original location on the C drive. How can I make VS C++ put everything related to my project "System Image" into the same directory structure on my D drive as shown above??
My OLD "test" project shows under solution explorer still. I assume I can delete that (I saved the cpp source elsewhere).
While we're there, I see I have:
Solution "test" - 2 projects ................................................with System Image and test being the 2 projects. Can I control what the solution "test" is called? Should it be named something particular?
System Image
test
Last edited by jlewand61; March 5th, 2012 at 08:42 PM.
Re: consolidating all libraries (user and VS C++ infrastructure ones)
Check your project properties. It sounds like you have setup a hardcoded path instead of a relative one.
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
Re: consolidating all libraries (user and VS C++ infrastructure ones)
That shouldn't be neccessary. I've moved projects to other locations as well as other computers with completely other path's and never had that issue.
The C: part of the path might origin from a VS macro or an environment variable.
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
Re: consolidating all libraries (user and VS C++ infrastructure ones)
I created a test project, built it, moved it, and rebuilt it without anything odd happening. The $(OutputDir) was automatically changed to reflect the new path (as it should).
In my test no absolute paths show up in neither the sln nor the vcxproj. Maybe you have hardcoded some project property at some point and that now overrides the normal behaviour?
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
Re: consolidating all libraries (user and VS C++ infrastructure ones)
I never did a thing other than a vanilla install UNTIL I moved the 3 primary libraries (projects and 2 templates) that are movable via the standard option panels.
I guess I have go through every single macro and see which ones point to C:.
Aha. It seems you can NOT change what the macro points to? IOW, there's no way to overtype the right-hand column that shows the definition of the macro.
Last edited by jlewand61; March 8th, 2012 at 09:16 PM.
Re: consolidating all libraries (user and VS C++ infrastructure ones)
Yeah, all of the projects settings are stuck inside those sln/vcproj files. It's easier to search through those text files than searching through all the settings in the IDE.
Also, there are settings for each individual file. You can see them by (IIRC) right clicking a .cpp file & choosing properties.
Re: consolidating all libraries (user and VS C++ infrastructure ones)
The macros that you see can be changed, but not in the macro window.
The $(OutDir) macro is changed in the project settings in the Project Properties. As shown here, changing the "Output Directory" will change $(OutDir); changing the "Intermediate Directory" changes $(IntDir), etc.
Hope this helps.
Be sure to rate those who help!
-------------------------------------------------------------
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
Re: consolidating all libraries (user and VS C++ infrastructure ones)
Thanks krmed, I think I get how this macro/panel interaction works now.
Can anyone answer my other question re: Solution explorer?
What makes the most sense? Having a CONSOLE and GUI "tree" in the main Solution Explorer panel? In my case, I think my main initial tree branch is called "test". Can I modify that? Is the intent to always have "all" ones projects showing in the Solution Explorer pane?
Re: consolidating all libraries (user and VS C++ infrastructure ones)
You can think of the "solution" as everything needed to build ONE complete application. For instance, if you are building an app called MyApp, and MyApp uses three DLLs and one library that you also created, your solution would contain fiveProjects:
MyApp
Dll1
Dll2
Dll3
Lib
You also then set the Project Dependencies so they are build in the correct order. For instance, if DLL3 requires something from the Lib, and DLL2 requires DLL3, and MyApp requires all of them, you would set the dependencies to indicate that. This guarantees that if you change something in the lib, the lib would be built first, then DLL3 would be re-built as needed, then DLL2, then MyApp.
As for "extra" projects that show in the solution explorer, you can simply delete them from the solution explorer - that removes them from the solution but does not delete the files on your disk.
Hope that helps.
Be sure to rate those who help!
-------------------------------------------------------------
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
Re: consolidating all libraries (user and VS C++ infrastructure ones)
OK. I looked through the sln and vcxproj files (3 of them?) and no C: hardcoded anywhere. I can only come to the conclusion that VS C++ isn't designed to coherently move files around.
Re: consolidating all libraries (user and VS C++ infrastructure ones)
krmed, so you're saying that I should have ONE solution per "solution" (project)?
Since I currently have "test" as my top-level "solution" of which BOTH system image and test are underneath that, what should I do to move stuff around and create a coherent view of my projects?
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.