Microsoft Visual C++/VC++, How to set up multi-developer, multi-executable software system

How to set up multi-developer, multi-executable software system

Author	Message
Joe Sewe #1 / 7	How to set up multi-developer, multi-executable software system We're working on an NT-based set of applications that will involve tons of code reuse (we're using Visual C++) across those applications. Right now, in our ignorance, we're "sucking in" all the source files as needed. The problem is, however, that if someone else makes a change, everybody else needs to know what new files to "suck in." When this doesn't get communicated, it's a royal PITA for everybody. Just FYI, we're using Rational ClearCase for source control management; the problem occurs when somebody makes a change to one application, other applications use the same files, but the person making the change isn't responsible for those other applications. It occurs to me that there MUST be a better way to do all this. There seems to be a tendency to avoid using DLL's, for reasons currently unknown to me (therefore I can neither justify the decision, nor can I condemn it, but let's assume, for the sake of discussion, that there's a good reason behind this decision). Right now we have 1 project per application. I'm wondering if there's a way to use a project file to "bundle" related source files (.cpp and .h) together without generating a separate linked file (.LIB, .DLL, or .EXE). How do other people handle this situation?
Tue, 09 Mar 2004 02:18:43 GMT

Rufus V. Smit #2 / 7	How to set up multi-developer, multi-executable software system All the source files don't have to be in the same directory. Put Shared code in a SharedCode directory and app-specific code in the project directory. Your source code management tool should be able to determine if your current local source is the same as in the archive. Who has the archive version "checked out", who last checked new software changes in, what's the difference between the old and new, etc. Don't allow code changes to sources which are not "checked out" by a developer, unless you want to get into branches and merges, which are great when properly understood and used, nightmare otherwise. Some source control systems can even generate email when modules are changed and rechecked in. Incidentally, people making changes to shared code ARE responsible for the other applications begin able to run with the changes. You should also be able to create labels for versions to recover the old working version when the new improved version doesn't work. People manage thje kind of stuff you are talking about all the time. Quote: > We're working on an NT-based set of applications that will involve > tons of code reuse (we're using Visual C++) across those applications. > Right now, in our ignorance, we're "sucking in" all the source files > as needed. The problem is, however, that if someone else makes a > change, everybody else needs to know what new files to "suck in." > When this doesn't get communicated, it's a royal PITA for everybody. > Just FYI, we're using Rational ClearCase for source control > management; the problem occurs when somebody makes a change to one > application, other applications use the same files, but the person > making the change isn't responsible for those other applications. > It occurs to me that there MUST be a better way to do all this. There > seems to be a tendency to avoid using DLL's, for reasons currently > unknown to me (therefore I can neither justify the decision, nor can I > condemn it, but let's assume, for the sake of discussion, that there's > a good reason behind this decision). Right now we have 1 project per > application. I'm wondering if there's a way to use a project file to > "bundle" related source files (.cpp and .h) together without > generating a separate linked file (.LIB, .DLL, or .EXE). > How do other people handle this situation?
Tue, 09 Mar 2004 04:15:11 GMT

Joe Sewe #3 / 7	How to set up multi-developer, multi-executable software system Quote: > All the source files don't have to be in the same directory. > Put Shared code in a SharedCode directory and app-specific > code in the project directory. > Your source code management tool should be able to > determine if your current local source is the same as in > the archive. Who has the archive version "checked out", who > last checked new software changes in, what's the difference > between the old and new, etc. > Don't allow code changes to sources which are not "checked out" > by a developer, unless you want to get into branches and merges, > which are great when properly understood and used, nightmare > otherwise. > Some source control systems can even generate email when > modules are changed and rechecked in. > Incidentally, people making changes to shared code ARE responsible > for the other applications begin able to run with the changes. > You should also be able to create labels for versions to recover > the old working version when the new improved version doesn't > work. > People manage thje kind of stuff you are talking about all the time. We're doing everything you're saying. I apologize for being unclear, but obviously I was. I'm talking about files from Visual Studio's point of view, not from the file system's point of view. For example, we have project A (a.k.a. A.dsp), which is under source control, which contains every source file required for that executable. Some of those files are also needed in project G (G.dsp). Now let's say somebody adds code to an existing class in project A that's also used in project G; further, let's say that it requires another source file, which is dutifully included into project A. The "owner" of project G, however, doesn't know beans about this change until she gets link errors. After tracing back, she discovers the need for the new files, adds them to project G, and moves on from there. This costs time, of course, time that could've been saved if there were some way to include files in some sort of "package" (again, from Visual Studio's point of view), and every project would just include the "package." It's possible that a simple .LIB would solve the problem; however, we're all relatively new at the Visual Studio environment, and I don't know of anybody here who knows how to create such a library containing C++ classes. I hope I've given a better explanation of what I'm getting at. - Hide quoted text - - Show quoted text - Quote: > > We're working on an NT-based set of applications that will involve > > tons of code reuse (we're using Visual C++) across those applications. > > Right now, in our ignorance, we're "sucking in" all the source files > > as needed. The problem is, however, that if someone else makes a > > change, everybody else needs to know what new files to "suck in." > > When this doesn't get communicated, it's a royal PITA for everybody. > > Just FYI, we're using Rational ClearCase for source control > > management; the problem occurs when somebody makes a change to one > > application, other applications use the same files, but the person > > making the change isn't responsible for those other applications. > > It occurs to me that there MUST be a better way to do all this. There > > seems to be a tendency to avoid using DLL's, for reasons currently > > unknown to me (therefore I can neither justify the decision, nor can I > > condemn it, but let's assume, for the sake of discussion, that there's > > a good reason behind this decision). Right now we have 1 project per > > application. I'm wondering if there's a way to use a project file to > > "bundle" related source files (.cpp and .h) together without > > generating a separate linked file (.LIB, .DLL, or .EXE). > > How do other people handle this situation?
Tue, 09 Mar 2004 20:45:42 GMT

David V. Corbi #4 / 7	How to set up multi-developer, multi-executable software system Re-Organize your source control. One umbrella project for ALL of your efforts. The sub projects for shared code and for each specific app. Do NOT have the files in more than one place in EITHER your file system or in source safe. As a suggestion, put the shared files in a seperate folder within the IDE, this greatly helps developers realize when they are making changes that can/will effect other projects. Quote: >-----Original Message----- Quote: >> All the source files don't have to be in the same directory. >> Put Shared code in a SharedCode directory and app- specific >> code in the project directory. >> Your source code management tool should be able to >> determine if your current local source is the same as in >> the archive. Who has the archive version "checked out", who >> last checked new software changes in, what's the difference >> between the old and new, etc. >> Don't allow code changes to sources which are not "checked out" >> by a developer, unless you want to get into branches and merges, >> which are great when properly understood and used, nightmare >> otherwise. >> Some source control systems can even generate email when >> modules are changed and rechecked in. >> Incidentally, people making changes to shared code ARE responsible >> for the other applications begin able to run with the changes. >> You should also be able to create labels for versions to recover >> the old working version when the new improved version doesn't >> work. >> People manage thje kind of stuff you are talking about all the time. >We're doing everything you're saying. I apologize for being unclear, >but obviously I was. >I'm talking about files from Visual Studio's point of view, not from >the file system's point of view. >For example, we have project A (a.k.a. A.dsp), which is under source >control, which contains every source file required for that >executable. Some of those files are also needed in project G (G.dsp). > Now let's say somebody adds code to an existing class in project A >that's also used in project G; further, let's say that it requires >another source file, which is dutifully included into project A. The >"owner" of project G, however, doesn't know beans about this change >until she gets link errors. After tracing back, she discovers the >need for the new files, adds them to project G, and moves on from >there. This costs time, of course, time that could've been saved if >there were some way to include files in some sort of "package" (again, Quote: >from Visual Studio's point of view), and every project would just >include the "package." >It's possible that a simple .LIB would solve the problem; however, >we're all relatively new at the Visual Studio environment, and I don't - Hide quoted text - - Show quoted text - Quote: >know of anybody here who knows how to create such a library containing >C++ classes. >I hope I've given a better explanation of what I'm getting at. >> > We're working on an NT-based set of applications that will involve >> > tons of code reuse (we're using Visual C++) across those applications. >> > Right now, in our ignorance, we're "sucking in" all the source files >> > as needed. The problem is, however, that if someone else makes a >> > change, everybody else needs to know what new files to "suck in." >> > When this doesn't get communicated, it's a royal PITA for everybody. >> > Just FYI, we're using Rational ClearCase for source control >> > management; the problem occurs when somebody makes a change to one >> > application, other applications use the same files, but the person >> > making the change isn't responsible for those other applications. >> > It occurs to me that there MUST be a better way to do all this. There >> > seems to be a tendency to avoid using DLL's, for reasons currently >> > unknown to me (therefore I can neither justify the decision, nor can I >> > condemn it, but let's assume, for the sake of discussion, that there's - Hide quoted text - - Show quoted text - Quote: >> > a good reason behind this decision). Right now we have 1 project per >> > application. I'm wondering if there's a way to use a project file to >> > "bundle" related source files (.cpp and .h) together without >> > generating a separate linked file (.LIB, .DLL, or .EXE). >> > How do other people handle this situation? >.
Tue, 09 Mar 2004 21:06:54 GMT

Bruce Dawso #5 / 7	How to set up multi-developer, multi-executable software system Use libraries. If you don't want to use DLLs (reasonable in many cases) use static link libraries. The library .dsp file will then contain a list of files for that set of functionality and every project that uses those libraries automatically gets the changes. For every executable that needs that functionality, add the .dsp file for the library to the workspace and set up dependencies so that the executable builds and links to the library. This is the correct way to solve your problem. Read the help files until you understand how to make it work. Quote: > > All the source files don't have to be in the same directory. > > Put Shared code in a SharedCode directory and app-specific > > code in the project directory. > > Your source code management tool should be able to > > determine if your current local source is the same as in > > the archive. Who has the archive version "checked out", who > > last checked new software changes in, what's the difference > > between the old and new, etc. > > Don't allow code changes to sources which are not "checked out" > > by a developer, unless you want to get into branches and merges, > > which are great when properly understood and used, nightmare > > otherwise. > > Some source control systems can even generate email when > > modules are changed and rechecked in. > > Incidentally, people making changes to shared code ARE responsible > > for the other applications begin able to run with the changes. > > You should also be able to create labels for versions to recover > > the old working version when the new improved version doesn't > > work. > > People manage thje kind of stuff you are talking about all the time. > We're doing everything you're saying. I apologize for being unclear, > but obviously I was. > I'm talking about files from Visual Studio's point of view, not from > the file system's point of view. > For example, we have project A (a.k.a. A.dsp), which is under source > control, which contains every source file required for that > executable. Some of those files are also needed in project G (G.dsp). > Now let's say somebody adds code to an existing class in project A > that's also used in project G; further, let's say that it requires > another source file, which is dutifully included into project A. The > "owner" of project G, however, doesn't know beans about this change > until she gets link errors. After tracing back, she discovers the > need for the new files, adds them to project G, and moves on from > there. This costs time, of course, time that could've been saved if > there were some way to include files in some sort of "package" (again, > from Visual Studio's point of view), and every project would just > include the "package." > It's possible that a simple .LIB would solve the problem; however, > we're all relatively new at the Visual Studio environment, and I don't > know of anybody here who knows how to create such a library containing > C++ classes. > I hope I've given a better explanation of what I'm getting at. > > > We're working on an NT-based set of applications that will involve > > > tons of code reuse (we're using Visual C++) across those applications. > > > Right now, in our ignorance, we're "sucking in" all the source files > > > as needed. The problem is, however, that if someone else makes a > > > change, everybody else needs to know what new files to "suck in." > > > When this doesn't get communicated, it's a royal PITA for everybody. > > > Just FYI, we're using Rational ClearCase for source control > > > management; the problem occurs when somebody makes a change to one > > > application, other applications use the same files, but the person > > > making the change isn't responsible for those other applications. > > > It occurs to me that there MUST be a better way to do all this. There > > > seems to be a tendency to avoid using DLL's, for reasons currently > > > unknown to me (therefore I can neither justify the decision, nor can I > > > condemn it, but let's assume, for the sake of discussion, that there's > > > a good reason behind this decision). Right now we have 1 project per > > > application. I'm wondering if there's a way to use a project file to > > > "bundle" related source files (.cpp and .h) together without > > > generating a separate linked file (.LIB, .DLL, or .EXE). > > > How do other people handle this situation?
Wed, 10 Mar 2004 00:15:37 GMT

Hans Dietric #6 / 7	How to set up multi-developer, multi-executable software system You can use static library (.LIB) to collect your common source files, and a common INCLUDE directory for the header files. Many people prefer this approach because it minimizes the number of components that have to be installed on user's system, and makes updating simpler (no dependencies to worry about). The only serious problem with dll's is versioning, especially if your company has several products that use same dll. The worst thing you can do is change version of dll without changing name of file. Also be sure to install your dll's in exe's directory, not in system directory. If you are careful about these issues, then dll's should be safe. Best wishes, Hans Quote: >> All the source files don't have to be in the same directory. >> Put Shared code in a SharedCode directory and app-specific >> code in the project directory. >> Your source code management tool should be able to >> determine if your current local source is the same as in >> the archive. Who has the archive version "checked out", who >> last checked new software changes in, what's the difference >> between the old and new, etc. >> Don't allow code changes to sources which are not "checked out" >> by a developer, unless you want to get into branches and merges, >> which are great when properly understood and used, nightmare >> otherwise. >> Some source control systems can even generate email when >> modules are changed and rechecked in. >> Incidentally, people making changes to shared code ARE responsible >> for the other applications begin able to run with the changes. >> You should also be able to create labels for versions to recover >> the old working version when the new improved version doesn't >> work. >> People manage thje kind of stuff you are talking about all the time. >We're doing everything you're saying. I apologize for being unclear, >but obviously I was. >I'm talking about files from Visual Studio's point of view, not from >the file system's point of view. >For example, we have project A (a.k.a. A.dsp), which is under source >control, which contains every source file required for that >executable. Some of those files are also needed in project G (G.dsp). > Now let's say somebody adds code to an existing class in project A >that's also used in project G; further, let's say that it requires >another source file, which is dutifully included into project A. The >"owner" of project G, however, doesn't know beans about this change >until she gets link errors. After tracing back, she discovers the >need for the new files, adds them to project G, and moves on from >there. This costs time, of course, time that could've been saved if >there were some way to include files in some sort of "package" (again, >from Visual Studio's point of view), and every project would just >include the "package." >It's possible that a simple .LIB would solve the problem; however, >we're all relatively new at the Visual Studio environment, and I don't >know of anybody here who knows how to create such a library containing >C++ classes. >I hope I've given a better explanation of what I'm getting at. >> > We're working on an NT-based set of applications that will involve >> > tons of code reuse (we're using Visual C++) across those applications. >> > Right now, in our ignorance, we're "sucking in" all the source files >> > as needed. The problem is, however, that if someone else makes a >> > change, everybody else needs to know what new files to "suck in." >> > When this doesn't get communicated, it's a royal PITA for everybody. >> > Just FYI, we're using Rational ClearCase for source control >> > management; the problem occurs when somebody makes a change to one >> > application, other applications use the same files, but the person >> > making the change isn't responsible for those other applications. >> > It occurs to me that there MUST be a better way to do all this. There >> > seems to be a tendency to avoid using DLL's, for reasons currently >> > unknown to me (therefore I can neither justify the decision, nor can I >> > condemn it, but let's assume, for the sake of discussion, that there's >> > a good reason behind this decision). Right now we have 1 project per >> > application. I'm wondering if there's a way to use a project file to >> > "bundle" related source files (.cpp and .h) together without >> > generating a separate linked file (.LIB, .DLL, or .EXE). >> > How do other people handle this situation?
Wed, 10 Mar 2004 17:13:32 GMT

Phil Boy #7 / 7	How to set up multi-developer, multi-executable software system If you have the time - look at the book "Large Scale C++ Development"(?) by Lakos. He can help with some of these issues. Quote: > We're working on an NT-based set of applications that will involve <snipped> > How do other people handle this situation?
Sun, 21 Mar 2004 01:53:43 GMT

Page 1 of 1

[ 7 post ]