[m-dev.] proposal: rename the --generate-module-order option

[Peter Wang]

On Tue, 19 Aug 2025 10:27:05 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Tue, 19 Aug 2025 13:32:38 +1000, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Mon, 18 Aug 2025 17:41:58 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> > The --generate-module-order option used to imply --generate-dependencies
> > until commit 1fcdc4cdc. You wrote:
> > 
> >     the new documented (and implemented) behavior is actually more useful,
> >     since it allows both options to be specified in Mmakefiles or
> >     Mercury.options files, have them be acted on when making dependencies,
> >     but not get error messages about incompatible op mode options.
> > 
> > Making it an only_opmode option is fine by me, but contradicts the
> > benefit you mentioned.
> 
> Yes, that is a good point. 
> 
> The problem I was trying to solve is that "mmc --generate-module-order prog.m"
> *looks* like it should do something (generate a .order file) that it does not do.
> Maybe a better solution is to rename the option to remove that impression.
> Some name such as --output-module-order-files-when-generating-dependencies
> would be expressive enough, but also too long. Does anyone have a shorter name
> that still works?

--also-output-module-order ?

> - the ability of 
> > > That's one proposal. The other is that regardless of whether
> > > we do the above or not, the name of the file we output to
> > > should be main_module.trans_opt_order, not simply main_module.order,
> > > since the former is much more expressive.
> > > 
> > > Opinions?
> > 
> > Actually, there's another "module order" file. The second file is named
> > .order_trans_opt. It records the module order for the purposes of making
> > .trans_opt files, which is affected by the --trans-opt-deps-spec option.
> 
> Looking at the code of compute_opt_trans_opt_deps_graph,
> the first file records the contents of ImpDepsGraph, while the second
> records the contents of TransOptDepsGraph. In the absence of
> --trans-opt-deps-spec, TransOptDepsGraph will be the transitive closure
> of ImpDepsGraph. My graph theory is a bit rusty, but my intuition says
> that the list of SCCs of the transitive closure should be the same as
> the list of the SCCs of the original graph. Does anyone know for sure?
> 

Yes, but don't quote me on it ;)

Some algorithms to compute transitive closure efficiently work on that
fact, e.g. the Purdom algorithm, see Esko Nuutila's thesis, page 20
<https://www.cs.hut.fi/~enu/thesis.html>

1. Detect the strong components of G and build its
    condensation graph G‾
2. Produce topological order of G‾
3. Compute the transitive closure of G‾
4. Convert that into the transitive closure of G

> Thanks for that info. But it seems I did not phrase question (c) well.
> When the compiler is asked to build module_x.trans_opt, where does
> the compiler get a list of the .trans_opt files that it is allowed to read
> in the process?

See maybe_read_d_file_for_trans_opt_deps; it's from the .d file.

Peter