asked on

Unit sharing in large similar projects

Hello everyone,

I am currently working on two projects with a lot (say 100) units. The projects are very much the same; therefore a lot of units are excatly the same. Different people work on the projects and the up-to-date source of all projects is never on one machine.

At this moment we work with two copies of the units that are the same. Every now and then I scan the two sources for differences. The two projects have the same name.

How can I determine wether a unit can be put into a shared directory and be used by both projects. What unit dependancies are allowed for this type of sharing sharing. Ideally the shared units are only compiled once for both projects. All types of unit dependencies are used in the projects.

So there are a number of cases that are distinguishable:

- candidate unit uses a project unit in the interface section
- candidate unit uses a project unit in the implementaion section
- candidate unit is used in a project unit in the interface section
- candiadte unit is used in a project unit in the implementation section

note: the units in both projects which are in the uses clause the candidate units have the same filename.

I have experimented a bit with this but am not sure yet which units to include in this sharing. I have seen strange behaviour: units not being recomplied while I expected they would be.

I hope to solve this problem soon. Maybe some people have experience with multiple similar projects and sharing units.

Regards Jacco

pjdb

Put the share untis in one folder and then add this folder in the default path for Delphi (Tools / Options / Library / Path) So that Delphi will find them. I'm doing this every day for some extension i've made to the delphi default functions and proc. These units are used either in the implementation or interface section.

I've never tryed to do so for unit that are using some units specific to the project. However, but you can specify a file (from the project directory) the be included in all file with
{$I Specification.pas}
in this file, you define your project with {$Define MyProject} and then, you will be able to define specific code (for the uses clause for example) in any unit by using
{$IfDef MyProject}
<come code for this project>
{$Else}
<some code all other projects>
{$EndIf}
Those {$<..>} command are used by the compiler to determine if he have to compile the lines or not. Specific code will not raise errors even if it's some meaningless stuuf if the current case

julio011597

Unless you have got particular requirements, a very common way is making dll's of those units, so to get rid of duplication at all. This also allowes modification of the shared code with no need to recompile the project source.

Regards, julio

rickpet

I would look into going to packages...place all your shared units into packages...

You should also consider getting a version control software...
We use PVCS by Intersolv. If money is an issue look at http://www.surehand.com/vcspro.htm this was originally written by Dr. Bob

Rick

Marcius

I agree with Rick, but would go one step further. Why don't you created components out of your units ? In the place where I am currently working, we are developing a LARGE billing system and are using components for the whole thing. The main form is essentially just a collection of tab pages etc onto which the components will be dropped. It works well.

Marc

ASKER CERTIFIED SOLUTION

altena

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Jacco

ASKER

Thank you all for responding.

I don't know what the rules are about the score distribution. Fair would be to give you all a share of the 100 I offered.

All options given sound good !

1) We will consider a PVCS for the managing of the modules.
2) We will build the most commom dialogs into a DLL
(I don't know how to implement form inheritance through a DLL
trying is the best I guess)
3) Custom components are already widely used, but I think the
use for a component is primarily visual/non visual
encapsulation of something. At most one TForm (like the
dialogs).
4) The {$I ....} and {$DEFINE etc are useful for the utility
units.

Again thank you all.

Regards Jacco