Using same source for different apps

[jeremy.todter]

I have a question...obviously

I am developing an application, or two applications using c++ and
openGL. They involve a basic structure where approximately 70 percent
of the framework applies to both projects, and each different project
has its own special funtionality. They are both very similar and exist
together, where the irrelevent menu items for example are greyed in one
and not the other. Each needs a different icon and title depending on
the application.

My problem is that there exists only one source. When I build the
release versions, I would like to be able to make these subtle changes
in both, whereby keeping the original source structure and not have to
edit parts for one and then go back and change them for the other.

I am sure, or hoping that there is some sort of build version system,
similar to CVS or something that will allow me to do this. I have
looked around but havent really found anything.

If anyone knows of anything or has any ideas that will help me out, can
you please let me know...

Thanks for your help, appreciate it.

J

[Stuart Redmann]

je***********@gmail.com wrote:

I have a question...obviously

I am developing an application, or two applications using c++ and
openGL. They involve a basic structure where approximately 70 percent
of the framework applies to both projects, and each different project
has its own special funtionality. They are both very similar and exist
together, where the irrelevent menu items for example are greyed in one
and not the other. Each needs a different icon and title depending on
the application.

My problem is that there exists only one source. When I build the
release versions, I would like to be able to make these subtle changes
in both, whereby keeping the original source structure and not have to
edit parts for one and then go back and change them for the other.

I rather do hope that you have created some inheritance hierarchy with a
lot of base classes that can be used by both projects. Furthermore, each
of these base classes should have its own header and implementation
file, so that you can make changes in these base classes without
changing any details that are specific to project-specific derived
classes. If your code isn't organized this way, you'll have the most
wonderful time re-organizing it. In the end your source tree should look
like this:

src
|_ common
| |_ BaseClass1
| |_ BaseClass2
| |...
|_ Project1
| |_ DerivedClass1_1 (with details that are specific to
| | project 1)
| |_ DerivedClass1_2
| |...
|_ Project2
| |_ DerivedClass2_1
| |...

Regards,
Stuart

[Puppet_Sock]

je***********@gmail.com wrote:
[snips]

I am sure, or hoping that there is some sort of build version system,
similar to CVS or something that will allow me to do this. I have
looked around but havent really found anything.

If anyone knows of anything or has any ideas that will help me out, can
you please let me know...

Sure there are build utils. But they are off topic in this news group.
You need to go to a platform specific news group for those. You
could start with a news group that talks about development in
your particular OS, or to do with your particular compiler. Google
up the news group or groups that have relevant stuff.

As far as organizing your code, there are plenty hints and tips
available if you are interested. The most simple of notions is
to use macro compile flags of some kind. When you compile
for one project, you have some extra include file, or your build
util sets flags for you, or some such. And this sets all the stuff
so that the first project gets what it needs. Then for the other
project you have a second include file, or a second make file,
or whatever your build util needs.

Another thing to look at is making a library for the common
features. Again, the details of how to make a library are
off topic here. For two projects, a library may, or may not,
be appropriate. There are plenty books on writing libraries.
The basic rule is: a feature probably belongs in the library if
nearly every client of the library will use it, at least now
and then. If only one client wants it, then it is unlikely to
belong in the library.
Socks

[noone]

On Wed, 08 Nov 2006 07:03:58 -0800, jeremy.todter wrote:

I have a question...obviously

I am developing an application, or two applications using c++ and openGL.
They involve a basic structure where approximately 70 percent of the
framework applies to both projects, and each different project has its own
special funtionality. They are both very similar and exist together,
where the irrelevent menu items for example are greyed in one and not the
other. Each needs a different icon and title depending on the application.

My problem is that there exists only one source. When I build the release
versions, I would like to be able to make these subtle changes in both,
whereby keeping the original source structure and not have to edit parts
for one and then go back and change them for the other.

I can't tell you how similar they need to be for this strategy to work in
you apps, but you could consider conditional compilation. Maybe consider
something like
c++ -DAPP1 source.cc
in the source.cc file

#ifdef APP1
cout << "app 1\n";
#else
cout << "other app\n";
#endif

When compiling with the APP1 symbol defined, the first clause will be
compiled, otherwise the second will. This is the best way for me to
include hardware level functions that work on one platform but are
different on the other.

But in keeping with the OO paradigm it is best to encapsulate the
application specific stuff in different classes and then only use
conditional compilation to instantiate the correct class. The optimizing
compiler shouldn't then include machine code for other than its intended
target.

class x8086_port_access; // x86 port access class
class arm_port_access; // arm port access class
#ifdef ARM
arm_port_access ports;
#else
x8086_port_access ports;
#endif
ports.set(ports::IRQ_CLEAR_REGISTER, ports::IRQ_ACK);

Assuming that the API for the classes are the same then the program will
only use the one for its target platform.

The above is only a hypothetical example so we need not discuss the
issues of class overhead when dealing with direct hardware access in
latency sensitive applications.