[m-rev.] for review: determine more minimal dependency relations
Fergus Henderson
fjh at cs.mu.OZ.AU
Fri Feb 15 16:28:49 AEDT 2002
On 14-Feb-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> Note that I can now build the dependencies for a 1000 sub-module
> hierarchy where various sub-modules import each other in 37 secs as
> opposed to 10 hours under the previous system.
Brilliant! That will make a big difference.
After this change is committed, I will be able to go back to my earlier
plan of converting the Mercury compiler to use sub-modules, with each
module in the compiler being a sub-module of one of the major components
(e.g. `ll_backend', `ml_backend', etc.).
> diff -u -r1.215 modules.m
> --- modules.m 8 Feb 2002 02:26:53 -0000 1.215
> +++ modules.m 14 Feb 2002 16:00:13 -0000
> @@ -2054,9 +2063,9 @@
> % parent modules also depend on the same things as the
> % `.date' files for this module, since all the `.date'
> % files will get produced by a single mmc command.
> - % XXX The same is true for the `.date0' files, but
> - % including those dependencies here might result in
> - % cyclic dependencies(?).
> + % Similarly for `.date0' files, except these don't
> + % depend on the `.int0' files as this would lead to a
> + % circular dependency.
Shouldn't there still be an XXX there, because the dependency
of the `.date0' files on the `.int0' files is a real dependency
which you have omitted?
Oh, now that I look at this a bit closer, I see the real reason.
The real reason why the `.date0' files for the parent modules
don't need to depend on the `.int0' files is because when
building the `.int0' files for this module and its parents,
the `.int0' files will each get produced by mmc before they are needed,
because mmc processes nested modules in outermost to innermost order.
E.g. for the following example,
:- module foo.
:- interface.
:- type t == int.
:- module bar.
:- interface.
:- type t2 == t.
:- module baz.
:- interface.
:- type t3 == t2.
:- end_module baz.
:- end_module bar.
:- end_module foo.
mmc will first build `foo.int0', then it will build `foo.bar.int0'
(in the process reading the `foo.int0' that it just generated),
and then it will build `foo.bar.baz.int0' (reading the two
`.int0' files that it built earlier).
The comment "as this would lead to a circular dependency" is misleading
and should be replaced, e.g. with something like "because, when doing
`--make-private-interface' for nested modules, mmc will process the
modules in outermost to innermost order so as to produce each `.int0'
file before it is needed".
> @@ -2694,11 +2710,69 @@
> %
> { relation__tc(ImplDepsRel, IndirectOptDepsRel) },
>
> + /*
> + write_relation("Rel", IntDepsRel, TransIntDepsRel, ImplDepsRel,
> + IndirectDepsRel, IndirectOptDepsRel),
> + */
> +
> generate_dependencies_write_d_files(DepsList,
> IntDepsRel, ImplDepsRel, IndirectDepsRel,
> IndirectOptDepsRel, TransOptDepsOrdering, DepsMap)
> ).
>
> +/*
> + % Output the various relations into a file which can be
> + % processed by the dot package to draw the relations.
> +:- pred write_relation(string::in, relation(sym_name)::in,
> + relation(sym_name)::in, relation(sym_name)::in,
> + relation(sym_name)::in, relation(sym_name)::in,
> + io__state::di, io__state::uo) is det.
> +
> +write_relation(FileName, IntDepsRel, TransIntDepsRel,
> + ImplDepsRel, IndirectDepsRel, IndirectOptDepsRel) -->
s/write_relation/write_relations/
Otherwise that change looks fine.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list