2.2.6 The "smartmake" feature

(You may skip this section if you're not curious and you're not going to create complex makefiles just yet).

The preceding sections have been referring to the "smartmake" feature a lot; what is it, actually? Smartmake is special code to take advantage of the fact that

Often, when a `.ui' file is remade, the unit interface it describes does not actually change.

Possible reasons why the `.ui' needed to be remade include

• Layout or comments in the corresponding `.sig' files were changed.
• There is no `.sig' file, and the `.sml' file was edited to change the implementation without changing its interface. The `.ui' got remade as a side-effect of compiling a new `.uo' file.
• Another `.ui' file that was necessary to compile this `.ui' file had a new timestamp without actually changing (or without actually changing anything relevant to this unit), so make considered the dependent `.ui' file out-of-date.

Note especially the last item. It means that the mere correction of a misspelled comment in a `.sig' file at the bottom of the dependency hierarchy can trigger a cascade of recompilations that means that most units in the program will be recompiled. This has a tendency to make programmers wary of fixing documentation errors in such units.

"Smartmake" is my codeword for a collection of black magic in Mosmake that makes make recognize when a freshly remade `.ui' file hasn't in fact changed, and thus stop the recompilation cascade at that point. Just because we can, the same treatment is applied to `.uo' files, such that you can fix a comment in an `.sml' file without needing to redo the entire link step.

Smartmake does not work with versions of GNU make earlier than 3.80. The early versions have bugs that prevent the black magic from working properly. If Mosmake detects that it runs on an old version of make, Smartmake will be turned off by default. Smartmake can be also turned on or off explicitly by giving `SMARTMAKE=yes' or `SMARTMAKE=no' on the make command line.

When Smartmake decides that a file which would have been recompiled without Smartmake does not need to be recompiled, it changes its timestamp such that the next make will not consider it out-of-date again. Thus you'll see a sequence of touch line in the output of make when Smartmake has been in action.

So that it can do this retouching, Smartmake must be able to sandwich some code in between the toplevel target you give on the make command line, and the actual compilation commands. That means that if you just type `make filename', the file will be built without Smartmake, even if Smartmake is otherwise turned on. Instead you must type type `make filename,smartmade'. (That is, the filename with the suffix `,smartmade' appended). If Smartmake is turned off, the `,smartmade' part does nothing.

When you just do a `make all', this happens for you behind the scenes. Mosmake will automatically declare that the default target `all' depends on `binary,smartmade' instead of just binary. But there are other situations where you must be aware of this, lest you lose the benefits of Smartmake:

• If you just want to build a single binary among several possible ones, you may want to say `make binary,smartmade' instead of just `make binary'.

• Likewise, if you just want to test-build, say, a `.uo' file in order to test for type errors in its source, you may want to do `make foo.uo,smartmade' instead of `make foo.uo'. Mosmake contains a pattern rule that will make this pattern work for all filenames as long as they are given on the make command line. Of course, you may also save the extra typing if you think that the savings form Smartmake in this particular build will not be worthwhile.

• If you want to let other metatargets than `all' depend on Mosmake-built programs -- say, if you have an `install-foo' target that makes sure that foo is up-to-date and then installs it somewhere -- you'll want to have the metatarget depend on `foo,smartmade' instead of just foo. Similary if you want (perhaps conditionally, based on configuration-time choices) to add a program declared %OPTIONAL to the `all' target.

• If you want make to run a Mosmake-built program to produce some output that is itself a target file, things begin to get difficult. You can't let the command that runs your program depend on `binary,smartmade', because in general no file with that name will ever exist, so the output from your program will be considered "always out of date" and regenerated each time make considers it. So the output file must depend on the binary itself, and if you want Smartmake to control the recompilation of the binary, you have to add the `,smartmade' step to the eventual target of the computations with its output.

Perhaps the last case ought to be explained through an example. Imagine that what you really want to do is to have something like this in the `Makefile':

...
include $(MOSMAKE)/Makefile.inc
rawdata: myprog
      ./myprog > rawdata
cooked: rawdata
      sort -u < rawdata > cooked
all: cooked
install: cooked
      cp cooked /usr/local/share/smurfs/cooked
.PHONY: all install

where Mosmake builds a single %OPTIONAL program called `myprog'.

Here, Smartmake will not be used to recompute `myprog' when you type `make all' or `make install'. Of course you can type `make install,smartmade' to enable the Smartmake each time, but you'll quickly tire of that. A better solution is to do

all: cooked,smartmade
install: cooked,smartmade
        cp cooked /usr/local/share/smurfs/cooked

or, even nicer yet in general,

all: cooked,smartmade
install: all
        cp cooked /usr/local/share/smurfs/cooked

Whatever you do, do not declare any `,smartmade' targets "phony" (see section `Phony targets' in The GNU make manual). Even though this in general sounds like the Right Thing to do, it will prevent make from finding the pattern rule that Mosmake uses internally to implement the `,smartmade' mechanism.