2.3.3 Introduction to mmc –make

The second Mercury build tool is mmc --make, which, as the name says, integrates the functionality of a make-like build tool into the Mercury compiler.

Like mmake, mmc --make needs access to the module-name-to-file-name map in Mercury.modules if some module in the program is stored in a file whose name does not match the module name, which means that the first step in buildin an executable is usually mmc -f *.m. Unlike mmake, when mmc --make is asked to build an executable for a program given the name of its main module, it can itself find out the the dependencies (importer-imported relationships) between the modules of the program; it does not need previously-built files containing makefile fragments to give it this information. It therefore has no need for any equivalent of the mmake main_module.depend command.

This allows an executable to be built with just these two commands:

mmc -f *.m
mmc --make main_module

It also gives mmc --make a subtle advantage over mmake: while mmake uses (because it has to) module-to-module dependency information that was current when the relevant modules’ were last (re)compiled (because that is when their .d files were last updated), mmc --make always uses current dependency information, because it gets that information from the current versions of the modules’ source files. Most of the time, the difference does not matter, for one of several reasons:

• because most changes to Mercury modules do not affect their :- import_module and :- use_module declarations;
• because deleting an :- import_module or :- use_module declaration cannot lead to obsolete versions of interface files being read (since they lead to fewer interface files being read);
• because when an :- import_module and :- use_module declaration is added, which can lead to obsolete versions of the interface files of the newly-imported modulees ubeing read, those interface files have a reasonably probability of of being brought up to date before being needed by the module that added the new import, due to some other module already depending on them; and
• because a nontrivial fraction of the time, the part of the interface file that bringing it up-to-date would change is of no relevance to the newly-importing module.

Most of the time, one or more of mitigating circumstances apply. However, sometimes none of them do. In such cases, using mmake to build the selected target will fail, with the failure being caused by mmake’s reliance on out-of-date dependency information (this could mean e.g. mmake not knowing that it must update the .int file of a newly-imported module before generating target language code for the importing module). In pretty much all of the usual scenarios, the attempt to build the target will cause the out-of-date dependency information to be updated, so the nect attempt to build that same target will succeed. Nevertheless the failure of the first attempt is usually annoying.

Such transient failures won’t happen with mmc --make, because it always works with up-to-date dependency information.

For more information on mmc --make, please see ZZZ