Specifying projects with makmake
tools.makmake
doclevel v6
this chapter documents makmake to e32toolp release 210 level.
Overview
EPOC projects are defined by an .mmp file which specifies the essential components of the project. The makmake tool is used to build makefiles for use in various environments. These makefiles are then used for project development. Some makefiles are built for use in building the project from the command-line, while others are for use with the MSVC++ IDE. For instance, starting with euhello.mmp, you can do:
makmake euhello wins
to build the makefile file euhello.wins.
You can now run:
nmake -f euhello.wins
to build the project from the command line.
To build the .dsp and .dsw files, designed for the Microsoft Developer Studio (Visual C++ 6.0), you can do:
makmake euhello vc6
For the ARM environment, you can do:
makmake euhello armi
nmake -f euhello.armi
to build the project from the command line (there is no IDE for ARM).
A command line makefile produced by makmake allows the executable (an .exe or any type of DLL) to be produced in one of two variants:
•	udeb - wide (UNICODE), debug mode
•	urel - wide (UNICODE), release mode
which may be selected by specifying the variant as a target. For instance, to build the udeb variant of the executable, you can do:
nmake -f euhello.armi udeb
The default for ARM is wide, release mode; the default for WINS and WINC is wide, debug mode. These default targets will be built if nmake is invoked with no target is specified.
If you build the executable using the MSVC++ IDE makefile, you may also need to run tools such as the bitmap and application information compilers, to build other aspects of the project. Command line makefiles will invoke these tools for you.
On the makmake command line, you may use path specifications to locate the .mmp file in any directory, eg
makmake ..\..\epoc32ex\e32\euhello armi
The generated .dsw and .dsp files are, however, always written into the current directory.
Invocation syntax
makmake [ options ] [source-path]project platform
platform :
	wins | winc | armi | arm4 | thumb | vc6 | vc6winc  | tools | vc6tools 

options :
	-d
	-v
	-mmp
	-plat

where
project	is the project to be specified	
source-path	specifies the path of the source .mmp file, relative to the current directory.
If omitted, the source .mmp file is project.mmp in the current directory.
Whether or not the source-path is specified, the generated makefile is always written in the current directory.	
Platform	is the target platform	
-d	indicates that the makefile is to be created in directory \EPOC32\Build\path_to_mmp_file\mmp_basename\platform rather than the directory in which makmake was invoked. Note that relative paths within the created makefile will be relative to the directory in which makmake was invoked so nmake should be invoked from that directory too if the project is to build correctly.	
-v	indicates verbose operation
When this flag is specified, makmake prints many progress messages.  The default is to give error messages only.	
-mmp
	Provides basic syntax guide to writing .mmp files instead of making the makefile.	
-plat platform
	Provides syntax guide to writing platform-specific sections of .mmp files, and information about which macros are defined for preprocessing the .mmp files.	

Normally, makmake generates a makefile whose extension depends on the platform:
•	for wins, the extension is .wins
•	for winc, the extension is .winc
•	for armi, the extension is .armi
•	for vc6 and vc6winc, the extension is .dsp
Generally, the makefile extension is the platform name preceded by a dot.
Projects can be built for ARM platform in three flavours, ARMI, ARM4 and THUMB.  These three flavours are termed “Application Binary Interfaces”, or ABIs for short.  ARMI is the ARM interworking ABI, ARM4 is the plain ARM ABI and THUMB is the ARM thumb ABI.  Projects built for ARMI can work with projects built in any of the three ABIs, while projects built for ARM4 and THUMB can only work with projects built for the same ABI or ARMI.  Projects built for THUMB use a different mode of ARM4 processing, where the processor handles instructions of 16 bits rather than 32 bits in length from a separate instruction set.
really all this needs to be explained in more detail somewhere else - and a link to that section introduced here.
Structure of project definition files
A makmake project definition file has extension .mmp and has the form
wholefile :
	statement-list
statement :
|	aif-stmt
|	asspabi-stmt
|	asspexports-stmt
|	assplibrary-stmt
|	bitmap-section
|	deffile-stmt
|	document-stmt
|	epocalldllentrypoints-stmt
|	epocheapsize-stmt
|	epocprocesspriority-stmt
|	epocstacksize-stmt
|	exportunfrozen
|	lang-stmt
|	library-stmt
|	linkas-stmt
|	macro-stmt
|	nostrictdef-stmt
|	resource-stmt
|	source-stmt
|	sourcepath-stmt
|	staticlibrary-stmt
|	strictdepend-stmt
|	systeminclude-stmt
|	systemresource-stmt
|	target-stmt
|	target-path-stmt
|	target-type-stmt
|	uid-stmt
|	userinclude-stmt
|	platform-specific-section
Each statement occupies a single line.
Note: a trailing backslash is used to indicate a line continuation.  Therefore, specify directories without their trailing backslash, eg systeminclude \epoc32\include, rather than systeminclude \epoc32\include\.
Use the C++ style comment syntax for comments. 
Specifying the target
Use the target statement to specify the file generated by the project.
Use the targettype statement to specify the kind of project:
Use the targetpath statement to specify where the project should be released.
target-stmt :
	target filename.ext
targettype-stmt :
	targettype target-type
target-type :
	app | dll | exe | exedll | fsy | ldd | pdd | epocexe | lib | ani | ctl | fep | mda | mdl | opx | pdl | rdl
target-path-stmt :
	targetpath target-path
For the target, specify only the filename with its extension.  The path for the released target will be chosen depending on the platform, variant, and release path:
•	for non-Win32 platforms, or for Win32 platforms when no release path is specified, the target will be released to \epoc32\release\platform\variant\
•	for Win32 platforms, when a target path is specified, that path will be interpreted as a location on the z: drive, and the release path will therefore be \epoc32\release\platform\variant\z\target-path\
makmake supports the following target types:
exe	an executable program. 
For an example, see introbld.exe-example.mmp.	
dll	a DLL — either a shared library, or a polymorphic interface. 
For an example, see introbld.dll.	
app	an EIKON application — linked with the NewApplication() function exported as ordinal 1. For an example, see introbld.eikon-example.	
exedll	an executable program for a multi-process platform, a DLL for a single-process platform.  
For an example, see introbld.eikon-exedll.	
ldd	a logical device driver.	
pdd	a physical device driver.	
Epocexe	an EPOC executable that can be launched from the shell.  This is an executable program which exports no functions under a multi-process platform and a DLL which is linked with the TInt WinsMain() function exported as ordinal 1 under a single-process platform.	
lib	a static library.	
ani	an animation DLL.	
ctl	a system control.	
fep	a front-end processor.	
mda	a media-server plug-in DLL.	
mdl	a mime recognizer.	
opx	an OPL extension.	
pdl	a printer driver.	
rdl	a recognizer.	
Specifying UIDs
tools.makmake.uids
Use the uid statement to specify the UIDs for a project.
uid-stmt :
	uid uid2 [uid3 ]
Each executable has three UIDs. The first is dictated by the target type of the project (whether a .exe or DLL). The second and third are optional. You specify only the second and, optionally, the third UID with the uid-stmt.
Under WINS, a separate source file is created with the generated makefile containing code to incorporate UIDs into the executable. The name of this file is created by taking the basename of the executable and adding the extension .uid.cpp. UIDs may be specified in either hex or decimal.
The uid-stmt applies exclusively to UNICODE builds of source now that NARROW builds are no longer supported by Makmake.
See also introbld.uids in Programming EPOC  |  The Build Environment.
Static interface DLLs
A static interface DLL represents an interface which is defined to its clients by one or more headers for use at compile time, and an import library (.lib) for use at link time.  Then, when a client executable is loaded at run-time, the loader notes that it requires the static interface DLL to be available.  The loader either loads the DLL or, if it is loaded already, attaches the new client to it.
Conventionally, the DLL is identified by name only.  In EPOC, all static interface DLLs must have a uid2 of 0x1000008d.  The particular static interface DLL is then identified by name and by uid3.  If a DLL called bossview.dll is built with uid3=0x10000252, then the name used in the import library for non-Win32 builds of EPOC is bossview[10000252].  The EPOC loader loads the bossview.dll, and checks that its UID is 0x10000252.  If the uid3 in the DLL does not match, then the load fails.
Polymorphic DLLs
A polymorphic DLL represents an interface defined with a gate function and an abstract class with at least one virtual function.  The polymorphic DLL exports the gate function at ordinal 1, which typically constructs a concrete class derived from the abstract interface.  The virtual function is then called, and the functions of the class are available.  Examples of polymorphic DLLs in EPOC include device drivers, EIKON application programs, and many more.
Each type of interface should specify its own UID, which is used as uid2 for the polymorphic DLL.  The function responsible for loading a polymorphic DLL (for example, the EIKON apprun program, or the E32 kernel) should check that its uid2 corresponds with the expected interface type.
For polymorphic DLLs, the interpretation of uid3 depends on the interface type.  uid3 may not be required by all interfaces.  The application architecture mandates that uid3 identify the particular application: the uid3 is used to relate an application program to its document files.
Since polymorphic DLLs do not produce an import library (.lib), the name mangling scheme used by static interface libraries is not used by polymorphic DLLs.
UIDs and Win32
The makefiles automatically generate UIDs for ARM executables, as part of the executable format.  For Win32 executables, this is not directly possible.  The source for such executables must contain the UIDs, and they must match with the UIDs specified in the project file.
Under WINS, UIDs are specified using syntax such as:
#pragma data_seg(“.E32_UID”)
__WINS_UID(0x10000079,0x1000006c,0x10000253)
#pragma data_seg()
This is only necessary for polymorphic DLLs — the Win32 loader does not check the UIDs of static interface DLLs. Source files containing the UID syntax are created automatically for Win32 executables when the makefile is created.
Specifying directories
Use the sourcepath statement to define the location of the project and its workfiles.
sourcepath-stmt :
	sourcepath sourcepath
The sourcepath should correspond to the directory containing the source files for the project specified after the sourcepath statement. If the sourcepath begins with a backslash then this directory will be considered an absolute source path, otherwise the directory will be treated as relative to the directory containing the .mmp file. Multiple sourcepath statements may be specified, but note that makmake will expect subsequent source and resource file statements to relate to the last previous sourcepath statement, or the directory containing the .mmp file if no sourcepath statement has yet been specified.
Temporary files will be built into directory \epoc32\build\path_to_mmp_file\mmp_basename\platform\variant\.
Specifying source files
Use the source statement to specify source files.
source-stmt :
	source source-file-list
Each source statement may specify an arbitrary number of source files.  Each source file should be specified including its extension, eg euhello.cpp.  There may be an arbitrary number of source statements in the project description file relative to each subproject.
Specifying document files
Use the document statement to specify source files.
document-stmt :
	document document-file-list
Each document statement may specify an arbitrary number of document files.  There may be an arbitrary number of document statements in the project description file relative to each subproject.  This keyword is only used in the creation of IDE makefiles, where it can be useful for specifying files so that they are available for editing within the IDE but do not play a part in building the executable.
The .mmp file is incorporated in the MSVC6 IDE by default, and the MSVC6 workspace can be regenerated using makmake once the .mmp file has been changed without the need to close the workspace first. To create a custom tool to do this in the IDE, Select Tools - Customise … - Tools.  In the dialog, choose an appropriate name for the tool, e.g. “recreate workspace”, and type “nmake.exe” as the command and “-nologo -f $(WkspDir)\$(WkspName).sup.make recreateworkspace” as the program arguments.  Leave the “initial directory” field blank, and tick the “Close window on exiting” checkbox.  Having edited the .MMP file for a project, select the new tool from the tools menu to recreate the workspace.  You will then be prompted to reload the new workspace.
Specifying resource files
If your project has a resource file, specify it using the resource statement.  If it is a system project rather than an application, use the systemresource statement.
resource-stmt :
	resource resource-file-list
systemresource-stmt :
	systemresource resource-file-list
Each resource file should be given with its extension, eg golf.rss
The resource and systemresource statements have almost identical functions.  Use the resource statement for applications: the makefile will build the resource file into the target directory.  Use the systemresource statement for system components: the makefile will build the resource file into \epoc32\release\platform\variant\z\system\data\ for a WINS or WINC build.  If more than one language is specified with the lang-stmt then each resource will be compiled multiple times, once for each language specified.
Specifying AIFs
If your project has an application information file, specify it using the aif statement.
aif-stmt :
	aif target-file source-path resource [ color-depth ] source-bitmap-list
The target file to be produced by aiftool should be given with its extension, eg golf.aif.  The source path should contain the source resource file and any bitmaps the target file requires.  If the source path is specified as a relative path it will be considered relative to the directory containing the .mmp file.  The source resource file should be given complete with its extension.  Just a single color-depth must be specified for all the source bitmaps, and must be of the form [c]digit[digit], where the optional “c” denotes whether the bitmap is a color bitmap and the digits represent the color-depth.  All the source bitmaps should be listed together with their extensions.
The target file will be created in the same directory as the application.
Currently, building of application information files within the MSVC IDE is not supported.
Specifying BITMAPs
If your project has a bitmaps, specify each one using a bitmap section.
bitmap-section :
	start bitmap target-file
	targetpath target-path
	header
	sourcepath source-path
	source color-depth source-bitmap-list
	end

The target file to be produced by bmconv should be given with its extension, eg golf.mbm.  If a target path is specified, that path will be interpreted as a location on the emulated z: drive; otherwise, the target file will be built into the same directory as the application.  If the header keyword is supplied in the section, a bitmap header will be generated in directory \EPOC32\Include, e.g. golf.mbg.  Multiple sourcepath and source statements can be specified - source bitmaps specified with each source statement will be expected to exist in the directory specified with the latest sourcepath statement above it, or the directory containing the .mmp file if no sourcepath statement has yet been specified.  Just a single color-depth must be specified for all the source bitmaps within a single source statement, and must be of the form [c]digit[digit], where the optional “c” denotes whether the bitmap is a color bitmap and the digits represent the color-depth.
Currently, building of bitmaps within the MSVC IDE is not supported.
Specifying link definition files
Use the deffile statement to override the default linker definition file for the project, and the exportunfrozen statement if unfrozen exports are to appear in the project’s import library.
deffile-stmt :
	deffile filename
exportunfrozen-stmt :
	exportunfrozen
A def file specifies associations between exported function names and their ordinal export number.  It is used by the linker when constructing a DLL and (where applicable) when constructing its associated import library.
Exporting functions by ordinal means that ROMs are significantly more compact, and simplifies the EPOC loader.
The assignment of ordinals must be controlled by a def file in two situations:
•	a polymorphic interface DLL must export a particular function as ordinal 1; in this case, the def file is used to specify this association, while other exported functions may have a random order
•	a re-released DLL must be used by clients built against the old version; in this case, the def file is used to ensure that all functions exported by the old version of the DLL are exported with the same ordinal by the new version
For many polymorphic DLLs within EPOC a special target type is provided so that makmake can ensure that the correct function is exported as ordinal 1.  Where a special target type is provided the def file can be dispensed with.
 def files are sometimes colloquially referred to as freeze files, because they freeze the association between name and ordinal, for exported functions.
The GNU and Microsoft tool chains use different schemes for mangling the names of exported functions.  This means that def files of the same name must be differentiated by storing them in separate directories.  Conventionally, ..\bmarm\ is used for ARM def files, while ..\bwins\ is used for WINS and WINC def files.  By default, the frozen def file takes its basename from the basename of the target for the project.  
Where the default frozen def file is overridden by the deffile statement, a path to the file can be specified as part of the filename. If no path is specified, the file will be expected to be in:
•	directory ..\bwins\ for platforms WINS, WINC, VC6 and VC6WINC
•	directory ..\bmarm\ for the ARM platform.
If a path is specified, place the deffile statement within #ifdefs so that the same file will not be used during both ARM,WINS and WINC builds. For example:
#if defined(WINS)
deffile-stmt
#else if defined(MARM)
deffile-stmt
#endif
(note that the platform name macros used with #if defs must be in upper-case).
In most cases, the functions exported from a DLL depend on the build variant.  This is common because descriptor class names depend on whether the build is wide or narrow.  For such DLLs, different def files — differentiated by the -u suffix — are used.  makmake controls this using the nostrictdef statement.  Although narrow builds are no longer supported the -u suffix is still in use to maintain backward compatibility with previous versions of makmake.
Note too that under WINS, when using an exedll target type, the first export is the one which will be called when the DLL is loaded, so you should use a def file for the WINS variant.
Makefiles generated by makmake now create the import library associated with an executable (where applicable) directly from the frozen def file, so only frozen exported functions will appear in the import library and only these exported functions can be linked against by other components.  For ARM platforms, import libraries for compatible ABIs are also created.  For example, if a project is built for ARMI then ARMI, THUMB and ARM4 import libraries will be created; and if a project is built for THUMB, ARMI and THUMB import libraries will be created.   If the exportunfrozen keyword is specified, the import library is not created from the frozen def file; instead, the import library is created as a side-effect of linking so that all exported functions, even unfrozen ones, appear in the import library.  This also means that import libraries for compatible ABIs are not created.  Use of the exportunfrozen keyword is only recommended for the early stages of project development, when the Application Programming Interface is likely to be subject to change.
The makefiles perform a two-stage link when building the executable:
The first link ignores any def file; it simply links the executable using the names of exported functions.
A tool is then invoked on the executable created by this first-stage link to produce a new def file containing the list of associations between exported function names and their ordinal export numbers. If a def file exists for the project, the tool takes the contained list of associations and ensures that the new def file contains the same list of associations; any new associations, representing new functions exported by the executable, appear at the end of the list. The new def file is created in the temporary files directory \epoc32\build\path_to_mmp_file\mmp_basename\platform\., and has the same base name as the executable with the extension .def. This is used to perform the second-stage of linking, by exported function number.
In VC6 workspace files building is carried out in the same way as for WINS makefiles, using a supplementary makefile to facilitate the two-stage link.  The supplementary makefile is created whenever the VC6 workspace file is created.  Since the supplementary makefile will not be aware of the addition or removal of a project’s source files via the menus supplied within the IDE, it is better to carry out such tasks by editing the .mmp file within the IDE and then regenerate the workspace file.  This operation can be carried out without the need to shut down and restart the IDE, and also has the advantage that the next time that command-line makefiles are created for the project they will be up to date with changes to the project made within the IDE.
Freezing export numbers
Use the frozen def file to ensure the backward compatibility of new releases of a project. If required, override the frozen def filename using the deffile statement.  To freeze exports for the first time, use makmake to build makefiles for your project for the WINS platform and an ARM platform and then build your project in either UDEB or UREL variants for each of these platforms (the three ARM platforms, ARMI, ARM4 and THUMB, share a common def file.  A warning will be generated to the effect that the frozen def file does not yet exist.  Once the project has been built you can freeze it by calling the FREEZE target in the makefiles, e.g. 
nmake -f <makefile> freeze
If you’re using the abld tool it’s easier to use the abld freeze command to do the freezing, which will call the FREEZE target in the makefiles for you.  Either method will create the frozen def file containing the project’s exported functions.  Once the project is frozen, regenerate the makefiles so that the import library will be created directly from the frozen def file.  The project can be frozen in this way even if the exportunfrozen statement is specified, but the import library will be created as a side-effect of linking rather than from the frozen def file, and this import library will be created whether the project is frozen or not.
Could do with a link to the abld documentation where abld is mentioned above.
New exports can be added to the frozen def file by calling the FREEZE target in the makefiles once the project has been built with the new exports incorporated.  The FREEZE target calls a tool, efreeze, to compare the frozen def file, if it exists, with the one generated by the two-stage link process in directory \epoc32\build\path_to_mmp_file\mmp_basename\platform\..  efreeze checks that the frozen exports are all present and correct in the generated def file, and appends any new exports to the end of the frozen def file.
Specifying strict link definition files
strictdef-stmt :
	nostrictdef
It is no longer necessary to specify the nostrictdef statement since there is always just one def file for the UDEB and UREL variants of a project for each platform.  If the nostrictdef statement is specified, the u suffix will not be applied to the frozen def file.
Specifying include directories
Use the userinclude and systeminclude statements to define directories to be scanned for files specified in #include statements in source and resource files.
user-include-stmt :
	userinclude directory-list
system-include-stmt :
	systeminclude directory-list
Each of these statements may be specified any number of times, and each may have any number of directories.  Each directory is added, in the order specified, to the list of user or system include directories.
When a project is being built, the pre-processor will be invoked specifying all the system include and user include directories indicated in these statements.  No standard include directories will be searched unless the project links to Win32 libraries under WINS - see tools.makmake.win32-libraries.
Files included from source code with a line such as
#include "golf.h"
will first be searched for in the directory containing the source file, then in the user include directories and finally in the system include directories.
Files included from source code with a line such as
#include <e32def.h>
will be searched for in the system include directories.
Specifying strict generation of dependencies
If your project’s dependencies may differ with the variant, use the strictdepend statement:
strictdepend-stmt :
	strictdepend
Without this statement, dependencies will be evaluated for one variant, and then used for all.  With strictdepend, dependencies are evaluated explicitly — a sometimes lengthy process — for each variant.
Use strictdepend if, for instance, you conditionally include a header file, e.g.
#if defined(_DEBUG)
include <debug.h>
#endif
Specifying import libraries
tools.makmake.specifying-libraries
Use the library statement to specify import libraries.
library-stmt :
	library filename-list
The library statement may specify any number of files, and there may be many library statements.  Specify the entire filename, e.g. euser.lib.
If you need to link to Win32 system libraries in a WINS build, use the win32_library statement instead: see tools.makmake.win32-libraries.
Specifying static libraries
Use the staticlibrary statement to specify static libraries.
library-stmt :
	staticibrary filename-list
The staticibrary statement may specify any number of files, and there may be many library statements.  Specify the entire filename, e.g. euser.lib.
Specifying language
Use the lang statement to indicate languages code for the project:
lang-stmt :
	lang language-list
If this statement is not specified, the default language code is sc.  The language codes should be two-digit codes, and are used to complete the extension of generated resource files, as project.rsc.  Each resource file specified with the resource-stmt will be compiled multiple times, once for each language specified, though the specification of several languages will not cause several versions of the bitmaps or application information files in your project to be created.
Specifying #defines
Use the macro statement to specify #defines for the preprocessing of source code:
macro-stmt :
	macro macro-list
Each macro specified will be defined for preprocessing the C++ source code in your project.  Each macro will be upper-cased before being defined, so it’s better to specify them in upper-case in the .mmp file.  Macro substitution is not supported - the macros will all be defined with the value “1”.
Specifying a non-default stack size
Use the epocstacksize statement to specify a stack size for your executable other than the default 8KB.
epocstacksize-stmt :
	epocstacksize stacksize
The size of the stack, in bytes, can be specified in decimal or hexadecimal format.  Use of this statement will have no effect under the WINS platform.
Specifying non-default heap sizes
Use the epocheapsize statement to specify minimum and maximum heap sizes for your executable other than the default 1KB minimum and 1MB maximum.
epocheapsize-stmt :
	epocheapsize minimum maximum
The sizes can be specified in decimal or hexadecimal format.  Use of this statement will have no effect under Win32 platforms.
Specifying the calling of dll entry points
Use the epoccalldllentrypoints statement to specify that the entry point, E32Dll(),  of your dll, should be called when your dll is loaded.  By default entry points are not called for non-Win32 platforms.
epoccalldllentrypoints-stmt :
	epoccalldllentrypoints
Use of this statement will have no effect under Win32 platforms, where entry points are always called.
Specifying process priority
Use the epocprocesspriority statement to specify the process priority for your executable EXE. Specify low, background, foreground, high, windowserver, fileserver, realtimeserver or supervisor.  The value specified will be passed on to petran via its -priority  switch.
epocprocesspriority-stmt :
	epocprocesspriority priority
Use of this statement will have no effect under Win32 platforms.
Specifying a different internal DLL name
Use the linkas statement to give the DLL that your project defines a different internal name.
linkas-stmt :
	linkas priority
By default, the internal name of the DLL will be the same as the DLL’s filename.  Under certain rare circumstances it’s useful to be able to give a DLL a different internal name.  For example, a DLL might be built with a certain name and then renamed as part of a ROM, so the internal name must be the same as the DLL’s name in ROM.
Use of this statement will have no effect under Win32 platforms.
Specifying ASSP items
ASSP stands for “Application Specific Standard Product”.  ASSP statements are for use by projects linking to the EPOC kernel, such as device drivers, so unless you are building such projects you can ignore this section.
assplibrary-stmt :
	assplibrary filename-list
asspexports-stmt :
	asspexports
asspabi-stmt :
	asspabi
The import library for the EPOC kernel and associated libraries are created in a directory corresponding to the hardware platform, or ASSP, a particular version of the kernel is built for.  For this reason, projects linking to the kernel must list ekern.lib with the assplibrary statement, to differentiate it from standard EPOC import libraries.
If the asspexports statement is specified, this means that the project exports different functions for different ASSPs; in other words, the API of a particular version of the project will correspond to the hardware platform that version of the project is built for.  The statement has two effects:
•	the import library for the project will be created in an ASSP-specific directory rather than in the usual directory for containing the ARM import libraries - \EPOC32\Release\assp-name\variant\ rather than \EPOC32\Release\platform-name\variant\.
•	the frozen def file for the project will, by default, reside in an ASSP-specific directory rather than ..\bmarm\.
If the asspabi statement is specified, the ABI that the project will be built for - ARMI, ARM4 or THUMB - will be the same as that of the kernel for a particular ASSP.  Otherwise the ABI for the project will be the default ABI for a particular ASSP.  The asspabi statement is implied by the presence of either the asspexports or the assplibrary statements.
This section is perhaps just going to confuse people, and maybe should just be in the base porting guide or the device driver documentation or somewhere like that.
Platform-specific items
A platform-specific section is enclosed in start and end:
start platform
	platform-specific-statement-list
end
The platform-specific statements allowed depend on the platform.  Unlike #if defined  blocks, which allow statements to specify different files dependent upon the platform for which the makefile is being created, start ... end platform blocks are used to delimit statements understood only by makmake when creating a makefile for a particular platform.  The makmake project definition file is preprocessed every time makmake is run, with the target platform defined as a macro equal to itself (where WINC is the platform, WINS is also defined).  This allows, for example, the project definition file to be preprocessed with the macro WINS defined as WINS so preserving the syntax of start WINS ... end blocks.  Where VC5 is the target platform, the macro WINS is defined instead; similarly the macros WINS and WINC are defined where the target platform is VC5WINC.
WINS-specific statements
tools.makmake.wins
Specifying a base address
Use the baseaddress statement to specify the address to which a DLL will be built and, if possible, loaded.
wins-specific-statement :
	baseaddress hex-constant
Use baseaddress to specify the base address of a WINS DLL.  Give each DLL a different base address, so that the Windows loader doesn’t have to do any relocation while loading EPOC and its DLLs.  This considerably speeds up the initialisation of EPOC under WINS.
Specifying Win32 system libraries
tools.makmake.win32-libraries
Use the win32_library statement to specify any Win32 system libraries needed by the project.
wins-specific-statement :
	win32_library filename-list
Use win32_library to specify Win32 libraries in the same way that other libraries are specified with the library statement.  If any Win32 system libraries are specified, directories specified by the INCLUDE environmental variable will be searched for system-included header files not found in the system include paths specified for the project.
Command Line Makefile utilities
Command-line makefiles created by makmake contain syntax which it is not possible to incorporate into makefiles intended for the MSVC IDE.  Command-line makefiles provide extra makefile targets which enable you to use nmake to create work directories and erase non-source files for a particular build variant of a project.  For example, WINS command-line makefiles provide the targets makework, makeworkudeb, makeworkurel, clean, cleanudeb, cleanurel.
nmake -f euhello.wins clean
will attempt to delete the non-source files created during a build of all variants of the project euhello, while
nmake -f euhello.wins cleanudeb
for example, will attempt only to delete non-source files created by a wide debug build of  the project.
nmake -f euhello.wins makework
will create the work directories for a build of all variants of the project euhello, while
nmake -f euhello.wins makeworkurel
will create the work directories for a wide release build of the project.
The build-specific makework targets are listed as dependencies of the main build-specific targets in command-line makefiles, so work directories will automatically be created when a target is built with a command-line makefile if these directories do not already exist.