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. 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 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 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 |
|
|
1. Multi record sets and multi databases
2. Multi record sets and multi databases
3. Multi-Threading, Multi-Functions, Real-Time, How?
4. DALLAS Senior Visual C++, MFC, Win32 Developers - multi-threaded applications
5. US-TX-Dallas Senior Developers, GUIs, MFC, Win32, multi-threaded applications 6
6. US-TX-Dallas Senior Developers, GUIs, MFC, Win32, multi-threaded applications 5
7. US-TX-Dallas Senior Developers, GUIs, MFC, Win32, multi-threaded applications 4
8. Security Software (Multi-Platform) Programmers Needed
9. Multi-User BBS software
10. Software Engineer III - MFC- Pre-IPO company, client/server, intranet, multi-threaded applications
11. Setting Affinity on multi processor machines
|
|
|