How to set up multi-developer, multi-executable software system 
Author Message
 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  
 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  
 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.

- 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  
 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

- 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

- 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  
 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  
 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  
 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  
 
 [ 7 post ] 

 Relevant Pages 

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

 

 
Powered by phpBB® Forum Software