> <\body> When using for the development of large mathematical programs which usually consist of lots of files, one should keep in mind one important design principle: <\quote-env> For any file which is to be compiled into a binary, the set of all dependencies for \ can be deduced from the source code in . Similarly, <\quote-env> For any file which is only to be compiled into an object file, the set of all dependencies for can be deduced from the source code in . As a consequence of these principles, the compilation process for large projects is easy to understand: the programmer should just make sure to carefully include the correct include files for every individual file in the project. The compiler will then take care of determining the various dependencies and compiling the files in the project in the right order and in parallel whenever possible. Notice that these rules are satisfied in several other programming languages such as C or C++: in this case, there is usually a makefile for the project which describes the dependencies and all kinds of compiler and linker flags which are necessary for building the executable. on the other hand does not require any particular configuration or makefiles in order to compile multiple file projects. Also the number of command line options is strongly reduced with respect to languages such as C or C++. In the case when some of the functionality of a program is imported from C++, the user should use the keywords , and in order to specify the dependencies on the C++ code and the particular compiler and linker flags to be used in order to compile the C++ code. We refer to the chapter on for more details. Other files can be included into a given file using the keyword >. provides three modes for the inclusion of other files: ordinary public inclusion, private inclusion and virtual inclusion. When including a file into the file using <\mmx-code> include "a.mmx"; all public functions, classes and categories from the file are made available in the file . Moreover, for any chain of public inclusions > > > > (we say that is indirectly and publicly included by ), the public functionality of is also available in . Public inclusions thus induce a dependency of on as well as of on for any file which indirectly includes . When building a large project in parallel, this means that both and will have to be recompiled whenever a change occurs in the public interface of . In order to reduce the number of dependencies inside a large project, it is possible to use the mechanism of private inclusions whenever appropriate. When including a file into the file using> <\mmx-code> private include "a.mmx"; all public functions, classes and categories from the file are made available in the file . However, the functionality of remains hidden for any other file which directly or indirectly includes (except when includes itself, or some other file different from , of course). On the other hand, if indirectly and publicly includes a file , then remains an indirect (although private) inclusion of , so all public functionality of is also available in . In summary, a private inclusion of in still induces a dependency of on , but the transitivity of the inclusion relation is broken. When using the mechanism of private inclusion, we still introduce dependencies for the build process: whenever the public interface of the included file changes, the file where the inclusion occurred needs to be recompiled. On some occasions, none of the functionality of is actually needed in or any other file which includes (directly or indirectly). Indeed, it may happen that we just want to ensure that some initialization code present in is executed before we start executing . For instance, the file might initialize some table which was declared in a file which is included both by and by , and such that the code in will only work correctly after initialization of this table. Whenever the above situation occurs, we may perform a virtual inclusion of into <\mmx-code> virtual include "a.mmx"; Virtual inclusions do not create any dependencies for the build process, but they do influence the list of files which need to be compiled and linked, as well as the order in which the various files of the project are executed (see section below). Whatever inclusion modes are used, no circular chain of inclusions is allowed in . In the case when some code in a file depends on some code in the file and , the programmer will have to explicitly include prototypes for the required functionality in one of the files. Class prototypes are declared using the syntax <\mmx-code> class Simple_Class; class Container (P_1: T_1, ..., P_n: T_n); Function prototypes are declared using the syntax <\mmx-code> fun (arg_1: T_1, ..., arg_n: T_n); <\itemize> Duplicate inclusions. Initialization only once, for the first inclusion. . If you don't have this file, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.>