[m-rev.] for review: extend modes of operation
Zoltan Somogyi
zoltan.somogyi at runbox.com
Mon Oct 12 19:38:31 AEDT 2015
On Mon, 12 Oct 2015 17:24:34 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>
> (I've just realised this wasn't going to the list.)
>
> On Mon, 12 Oct 2015, Julien Fischer wrote:
>
> >
> > On Mon, 12 Oct 2015, Julien Fischer wrote:
> >
> >> On Mon, 12 Oct 2015, Zoltan Somogyi wrote:
> >>
> >>>
> >>>
> >>> On Mon, 12 Oct 2015 11:12:23 +1100 (AEDT), Julien Fischer
> >>> <jfischer at opturion.com> wrote:
> >>>> The diff itself looks fine
> >>>
> >>
> >> Actually, that said, there appears to be at least one more exception
> >> required (this is when building the standard library with mmc --make):
> >>
> >> Making Mercury/int3s/version_bitmap.int3
> >> Making Mercury/int3s/version_hash_table.int3
> >> Making Mercury/int3s/version_store.int3
> >> Making Mercury/int0s/thread.int0
> >> Error: only one of the following options may be given:
> >> `--make-private-interface', `--target-code-only' and `--compile-only'.
> >
> > According to compiler/handle_options.m:1014 the latter two are always
> > enabled when --make is. '--make' is always passed through to the its
> > subprocesses, although that seems unnecessary as we also pass
> > '--invoked-by-mmc-make'.
>
> Does anyone know why we do the following at
> compiler/handle_options.m:1014, it doesn't actually seem necessary.
>
> option_implies(make, compile_only, bool(yes), !Globals),
> option_implies(make, target_code_only, bool(yes), !Globals),
>
> If it *is* necessary then we shouldn't be doing until after we have
> checked the value of --invoked-by-mmc-make and potentially disabled
> --make (a few lines further down).
A "git log" says that those two lines were introduced by commit 9c9601808da2f36a45462965d67dcbcae71b4356 in march of 2002
by Simon Taylor when he added --make to the compiler, so they
have been there as long as mmc --make itself.
I haven't been in touch with Simon in a long time, so I can't ask him.
You could try doing what you suggested, and seeing whether that works.
(I can't do the same, because I don't typically compile anything with
mmc --make, and thus can't pick up changes anywhere as reliably.)
I think the right way forward in the longer term is to make mmc --make control
each step of making its target not by setting the values of binary options,
but by setting the mode of operation. We could get the various submodules
of make.m, and maybe the rest of the compiler except for handle_options.m,
cease paying attention to the values of the boolean options that influence
the mode of operation, and start paying attention to the mode of operation
itself. I am willing to make that change, but I would need someone to give me
a good, tough, realistic test case for mmc --make. Does anyone have any code
they could volunteer?
Zoltan.
More information about the reviews
mailing list