 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2006c++ project structures
Okay, it's been a while since I've managed large projects in vs c++. So I've got a project structure question. I have about 5 projects that I am bringing into MC++ VS2005 (from VS 6). I've got 2 of these projects converted, compiled, and running so far. But all 5 of the projects share some of the code, in a way that needs to be changed. Right now, each project contains code files within its project directory. So if I make a change to codefile1.cpp or codefile1.h that is shared across all 5 projects, I have to make that change across ALL FIVE PROJECTS. What I would like to do is move these out to a common shared directory and have one solution that includes all the projects, but I still want to use relative path names on my includes. (My initial attempt at this forced me down a route to explicity label the path that the include file was in, which is NOT what I want). Obviously, I need a little direction. > Right now, each project contains code files within its project > directory. So if I make a change to codefile1.cpp or codefile1.h that [quoted text clipped - 4 lines] > initial attempt at this forced me down a route to explicity label the > path that the include file was in, which is NOT what I want). In these cases my configuration is usually: all shared files are in $(SolutionDir), all projects are in separate folders under $(SolutionDir), all project specific files are in theirs $(ProjectDir), and for all projects and all configurations add "$(SolutionDir);$(ProjectDir)" in Additional Include Directories. Having all files have unique names is a requirement. Mihajlo Cvetanovic wrote: > In these cases my configuration is usually: all shared files are in > $(SolutionDir), all projects are in separate folders under > $(SolutionDir), all project specific files are in theirs $(ProjectDir), > and for all projects and all configurations add > "$(SolutionDir);$(ProjectDir)" in Additional Include Directories. How will this configuration affect my precompiled headers? If I keep the precompiled headers in the main directory (or in the search path) will that suffice? Thanks, Sharon > How will this configuration affect my precompiled headers? If I keep > the precompiled headers in the main directory (or in the search path) > will that suffice? Precompiled header is just an ordinary header that has only performance related special meaning to the compiler. I use precompiled headers w/o problems. Of course when you rearrange source files you'll need to do a full rebuild. On the second thought, if you #include a project specific header in the precompiled header I don't know what would happen, but you shouldn't be doing that anyway. Only things that don't change in project compilation can/should be precompiled. Mihajlo Cvetanovic wrote: > On the second thought, if you #include a project specific header in the > precompiled header I don't know what would happen, but you shouldn't be > doing that anyway. Only things that don't change in project compilation > can/should be precompiled. Yes, there are project-specific headers included in the precompiled headers. These projects have had no central management nor source control in place before I got here...I'm afraid I'm in for a large clean-up. Just want to make sure I follow standards while doing it. Thanks, Sharon > Yes, there are project-specific headers included in the precompiled > headers. These projects have had no central management nor source > control in place before I got here...I'm afraid I'm in for a large > clean-up. Just want to make sure I follow standards while doing it. I have played a bit with this "project specific stuff in stdafx.h" thing, and managed to make it work. One solution (Test), two projects (Test1 and Test2), and #include "project_specific.h" within stdafx.h. In Test1\project_specific.h there's a line static const int number = 1; and in Test2\project_specific.h it's "= 2;". In Test1's main() there's cout << "1 = " << number << endl; and in Test2 there's "2 = ". When Test1 is run the result is "1 = 1", and when Test2 is run the result is "2 = 2". You need to remove existing stdafx.* from both projects, put files stdafx.cpp and stdafx.h to Test folder, add them to both Test1 and Test2 projects, set stdafx.cpp PCH option in both projects to "Create Precompiled Header", and add $(ProjectDir);$(SolutionDir) to both projects in "Additional Include Libraries". It's easier to do it than to explain it :) The conclusion is that it can be done, if you're careful enough. Gotcha. Thanks for the info. I'll give it a go. Cheers. Sharon > Okay, it's been a while since I've managed large projects in vs c++. > So I've got a project structure question. [quoted text clipped - 14 lines] > > Obviously, I need a little direction. A couple thoughts of my own - First, I'd avoid shared files like the plague, with the exception of header files that define the public (only!) interface to libraries. If you have non-header source files that are shared, the solution needs to be refactored to move those modules into a library or DLL of their own. Second, the definitive work on the subject is this one: http://www.amazon.com/gp/product/0201633620 -cd > First, I'd avoid shared files like the plague, with the exception of header > files that define the public (only!) interface to libraries. If you have [quoted text clipped - 5 lines] > > -cd There are non-header source files, and I had considered creating libraries for them...problem is, they don't lend themselves to any clear organization. Could just lump them all into some "common" library, but it doesn't feel right. There are IO functions, graphics display functions, security functions, and the list goes on. I'm thinking since there is so much common functionality, we instead have one application focused on our core product and include the several other projects as tools. Thanks for the info. Regards, Sharon
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.