Frank Heckenbach wrote:
- new options `--[no-]propagate-units' (on by default with `--mac-pascal', off in other dialects) (fjf987*.pas) (M)
Here are some additional notes about the --[no-]propagate-units flag.
1. Compilation speed
In GPC, loading .gpi files is a recursive process of order O (2). This means that:
- the more units, the slower GPC becomes - in large projects with many units, most time is spent in loading and reloading of .gpi files.
The workaroud is to:
(a) activate --propagate-units (this copies .gpi data of used units into the .gpi file of the compiled unit) (b) remove all USES clause entries for units that are no longer needed (because they are not used at all or because of the --propagate-units flag) (c) use gp instead of gpc (gp works very well and doesn't have the bugs of --automake)
This will lead to a dramatic increase in compilation speed for large GPC projects.
2. Master units
Suppose, we have a program P that uses units tb1, tb2, tb3, tb4, representing a custom toolbox, plus some other units
program P; uses tb1, tb2, tb3, tb4, util1, util2; ...
Now, we can put toolbox units tb1, tb2, tb3 and tb4 in a master "toolbox" unit
unit toolbox; interface uses tb1, tb2, tb3, tb4; end.
and use it in P instead of tb1 ... tb4
program P; uses toolbox, util1, util2; ...
We have gained the freedom to make interface changes to tb1 .. tb4, without the need of changes at a higher level (e.g. you can add a unit tb5 or move a routine from one tb unit to another).
3. Local use
The compiler directives {$propagate-units} and {$no-propagate-units} can be used for fine-tuning or selective unit-propagation.
Regards,
Adriaan van Os