6.1 Creating and Customizing Profiles

A profile is an alist providing values for Oz mode variables and environment variables. The best way to create and customize profiles is through Emacs's customize interface. For example M-x customize-variable RET oz-profiles will provide you with an interactive customization sheet as shown in Figure 6.1.

Figure 6.1: Initial Customization Sheet

We create a new profile by clicking the INS (insert) button, and obtain a new entry as shown in Figure 6.2 with many possible settable parameters.

Figure 6.2: After Clicking INS

Fortunately, you never need to specify many of them. All the others take appropriate default values.

6.1.1 Global Profile

For example, let's define a profile to use the globally installed Mozart in the usual fashion. Here are the steps to follow:

Give a name to the profile, e. g. global.
Select type installed from the value menu for the Type parameter. This type information allows other important settings to be automatically computed.
Select the OZHOME parameter by clicking in the box, and then set its value to the directory of an installed Mozart system. For example /usr/local/oz.

We arrive at the profile customization shown in Figure 6.3. Don't forget to save it by clicking the Save For Future Sessions button.

Figure 6.3: Global Profile

6.1.2 Default Profile

A so-called default profile consists of whatever settings were present in your environment when you started Emacs. This is for proper operation when you actually choose to invoke oz rather than plain emacs: in that case, the default profile consists of the settings established by the oz script. You can also create a default profile:

Give a name to the profile, e. g. default
Select type default

The only reason to have a named default profile is so that you can revert to the original settings in force when you started oz by switching to this profile.

6.1.3 Build Profile

Developers may find it marginally convenient to be able to define a profile where the emulator and all modules are looked up directly in the build tree. Here are the steps to follow:

Give a name to the profile, e. g. build
Select type build
Set the source directory: this is the top directory in which you checked out the Mozart sources
Set the build directory: this is the top directory in which you built the Mozart system

For example, Figure 6.4 shows typical build settings on my laptop.

Figure 6.4: Build Profile

6.1.4 Debug Profile

Developers will find it particularly convenient to be able to define debug profiles, i. e. build profiles for builds configured with --enable-opt=d, and, in particular the ability to state that they should be run under control of GDB. Here are the steps to follow:

Give a name to the profile, e. g. debug
Select type build
Set the source directory
Set the build directory
When compiling a debug emulator you really don't want to recompile the entire system, and in particular not the libraries because that is rather slow with a debug emulator. So, typically you will configure with --enable-opt=d, but then you will cd platform and invoke make bootstrap there. Yet, in order to run the system you need the rest too. This is why it is possible to specify a second build directory: this is supposed to be your usual build directory, not the one configured for debugging. By setting the second build directory, everything not found in the debug build directory is looked in the second build directory.
You can optionally, state that the debug profile should be started under control of GDB: select item Run under GDB, then select e. g. Yes + Auto Start from its value menu.

For example, Figure 6.5 shows typical debug settings on my laptop.

Figure 6.5: Build Profile

Note that any profile can be set to run under GDB, but this is rarely useful except when used with a debug emulator.