[m-dev.] Transitive Intermodule Optimization

[Simon Taylor]

Hi,

Chris wrote:
> [transitive inter-module optimization]
>
> Using a .order file.
> 
>     Problems:
>      - The information in the .order file would only be updated when
>        mmake <module>.depend is run, which is not very often.

Maybe the code to update the .d files at each compilation could
read the old .d file, check whether the dependencies of a module 
have changed and warn that an mmake depend may be needed if they have.

>      - When circular dependencies exist between modules (x imports y,
>        and y imports x), it would be difficult to break these
>        circularities in an optimal way. (currently our best solution is
>        to impose alphabetical ordering to break cycles).  In particular,
>        when x imports y for types only, then it would be preferable if y
>        appeared above x in the ordering.

Finding out which items are used from an imported module is not easy 
when generating dependencies. If there are circular dependencies introduced 
by importing types the types should be separated out into another module.

> .opt2 .opt3 ... files.
>     This solution would store transitive intermodule information in a
>     series of files, such that each file could only depend on files
>     which come earlier in the series. (so, m.opt3 could depend on
>     m.opt2, but not the other way round). 

> Track and update dependencies locally, ensuring that circularities
> cannot develop.

These might be overkill.

I think using the .order file and warning when the dependencies change
is probably good enough. You need to do most of that for the more involved 
methods anyway, so if you later want something more accurate you haven't
wasted too much effort. Just document somewhere that mutually recursive 
module imports are bad for termination analysis.

Simon.