The positive form is enabled by default, being provided by CL as an initial option. The positive and negative forms override each other, but weakly. Additionally, the /ZM option weakly overrides /Yc and /YX, and is overridden by them.


The /ZM option, positive or negative, affects how CL proceeds through the various stages of compilation when presented with more than one compilable source file. The possible stages are:

  1. compiling (done by C1 or C1XX, for C or C++ source files respectively, else by modules named with /B1 or /Bx);
  2. processing (not ordinarily enabled, else done by whatever module is named with /B1_5);
  3. generating code (done by C2, else by whatever module is named with /B2).

Whether all these stages are wanted depends on other options. The /BK option disables the first (though with requirements that make it not at all useful for a batch operation). The /E, /EP, /P, /Zg and /Zs options enable the first but disable the others. Complete compilation to an object file requires the first and last stage, which are enabled by default.

Basic Sequence

The basic behaviour, as obtained with /ZM-, is to put each compilable source file through each applicable stage before proceeding to the next source file. The given ordering of the compilable source files is respected absolutely: if source file A precedes source file B on the CL command line, then source file A goes through all its compilation stages before source file B goes through any.

Consider, for example, a batch that would compile two C source files, TEST1.C and TEST2.C, two C++ source files, TEST3.CPP and TEST4.CPP, and two more C source files, TEST5.C and TEST6.C, all the way to object files. The command

cl [options] /ZM- test1.c test2.c test3.cpp test4.cpp test5.c test6.c 

(with it assumed that the options include none that suppress any stages or name alternative modules) is handled in the order

The /ZM- order has the advantage of economy with disk space. Because all work with one source file is completed before doing anything with the next source file, the intermediate files that C1 or C1XX produce as input to C2 while working on the one source file can be deleted before any more intermediate files are created for the next source file. The demand for disk space is just for the largest set of intermediate files needed for any one source file. (In reality, CL is not quite this efficient.)

Against this economy is the waste of repeatedly reloading the compiler modules C1, C1XX and C2. These are moderately large, such that (if only historically) the loading of one has a non-negligible chance of displacing another, whether from a disk cache or from physical memory, and the reloading then suffers from time spent on disk access. A reordering that reloads less often may be expected to work faster, which may have been the motivation for /ZM.

Modular Sequence

The behaviour enabled by /ZM favours persisting with each compilation stage for multiple source files before proceeding to the next stage. The given ordering of the compilable source files is respected only for the first stage: if source file A precedes source file B on the CL command line, then source file A goes through its first stage of compilation before source file B goes through its first.

The present algorithm splits the given sequence of compilable source files into subsequences (batches) such that

The source files in each subsequence are put one by one through the first applicable compilation stage, then one by one through the second stage, etc, for as many stages as apply. Each progression to another stage omits source files that failed the previous stage. It also reverses the ordering of source files, presumably to increase the chance that the source files and corresponding intermediate files to be worked with near the start of one stage are still cached from the work done on them near the end of the previous stage.

For the example given above, but now with /ZM, the order changes to

The /ZM order is more economical with reloading compiler modules than is the /ZM- order, but requires more disk space for intermediate files. With a batch of source files being put to C1 or C1XX before any of that batch are put to C2, there must be sufficient free disk space to save one set of intermediate files for each source file in the batch. The present limit on the batch size is one source file plus one more for every 3 million bytes of free space on whatever drive is to hold the intermediate files, up to a maximum of 20.