2.1 Introduction

2.1.2 Introducing the MLWorks project system

Application sources are typically decomposed into a collection of separate source files. These files may depend on one another in complex ways, in which case when you ask MLWorks to compile a file, it also compiles all the files that your file depends on. MLWorks handles this using a project file which is used to compile ML source files to object files in an organized and flexible way.

When it compiles a source file, MLWorks produces an object file, which contains an internal representation of the objects defined by the code; and it can then load those objects into the interactive environment. If an object file already exists, MLWorks does not need to compile the source file; it can just load the objects directly from the object file.

Using object files is much faster than re-compiling every file whenever you change it or re-start MLWorks. However, it would be inconvenient if you had to keep track of object files and remember which ones needed re-compiling. The project system does this tracking for you, only compiling a given source file if it has been changed since the last time it was compiled, or if it has never been compiled before.

The MLWorks project system also provides two different notations for describing the locations of source and object versions of your application's files. Using relative path names allows you to compile different versions of the application files stored in matching directory structures by simply copying the project file to a different location, whereas using absolute path names provides a fixed reference to the application files, regardless of where the project file is saved. Both relative and absolute path name specifications are discussed in greater detail in Section 2.3.2.