[m-dev.] interface files

[Zoltan Somogyi]

Is there any documentation about what is supposed to go into each kind
of interface file (.int0, .int3, .int2 and .int), and what principle governs
the contents of .d files, of apart from the comments in modules.m?

The reason I ask is that I would like a fix for a problem that has been
annoying me for a few months. The problem is that if I make a change
that should be purely internal to a module in the compiler, such as
defining a new local type or adding a private import_module, mmake
often decides to remake everything.

I originally thought that the main problem was that the .int2 file
contained too much information: it contains local type definitions
and local imports, even if they aren't required to fully module qualify
a type that occurs on the right hand type of a type equivalence
in which the type on the left hand side is exported from the module.

I still think this is a problem, but now I think another problem may be
more important. This is that the .d files make each file dependent on
the .int2 files of too many other modules. A simple grep for
check_hlds.typecheck.int2 in compiler/*.d shows that check_hlds.typecheck.int2
is included in just about all the .d files in the compiler directory.
The exceptions fall into two categories. The unsurprising category
is the .d files of modules in the libs package and of gcc.m, which don't
import any submodule of check_hlds.m in any way, directly or indirectly.
The surprising category is several other submodules of check_hlds.m.
So we have a situation in which fellow submodules of check_hlds.m
don't depend on check_hlds.typecheck.int2, while submodules of other
top-level modules, such as aditi_backend.m do depend on
check_hlds.typecheck.int2. A spot check of the dependencies of modules
on some other .int2 files showed the same pattern. I can see no
justification for these dependencies.

I suspect the culprit is the transitive closure operation in modules.m
Simon introduced with his changes in december; the problem seems to date
from then. However, cannot be sure about the right fix without more
information or a lot more work.

I hope this jogs something in Simon's memory, and he can either fix the
problem, or give me the documentation that I need to fix it myself.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------