BMK

BMK is a command line tool that drives the BlitzMax compiler and provides other general 'housekeeping' operations.

The general syntax for BMK is: bmk Operation Options Arguments

Legal operations for BMK are:

Makeapp

Makeapp builds an application from a single root source file. Building an application involves compiling source files and linking together the resultant object files.

Makeapp takes one argument: the root source file to be built.

The root source file is scanned by BMK for Import, Include and Incbin statements, and these files are automatically built as well.

Unless the -a option is used, only source files that have been modified since the last makeapp operation are recompiled. This can vastly improve compile times.

Valid options for makeapp are:

OptionEffect
-rBuild release version. By default, the debug version is built.
-o OutputFileSpecify output file. By default, the output file is placed into the same directory as the root source file.
-aRecompile all source files regardless of timestamp. By default, only files modified since the last makeapp are recompiled.
-f FrameworkModuleSpecify a framework module. By default, all modules are automatically imported when building an application.

Some examples of makeapp in action:
bmk makeapp myapp.bmx
bmk makeapp -a -r -o myapp_release myapp.bmx

Makemods

Makemods builds a set of modules.

Makemods takes one optional argument: a module filter. This can be a module scope name (to build a subset of modules) or a fully qualified module name (to build an individual module). If the module filter is omitted, than all modules are built.

Valid options for makemods are:

OptionEffect
-dBuild debug version. By default, both debug and release versions are built.
-rBuild release version. By default, both debug and release versions are built.
-aBuild all modules regardless of timestamps. By default, only modules that have been modified are built.

Some examples of makemods in action:
bmk makemods mymods
bmk makemods -a mymods.testmod

Syncmods

Syncmods synchronizes modules over a network. This involves comparing local module version numbers with remote module version numbers, and downloading and installing out of date modules.

Syncmods looks for a file called cfg/modservers.cfg in the main blitzmax directory. This file should contain a newline separated list of module server URLs.

Valid options for syncmods are:

OptionEffect
-u UsernameUsername for synchronization. Depending on how the module server is configured, it may be necessary to provide a valid username and password. The default username is 'nobody'.
-p PasswordPassword for synchronization. Depending on how the module server is configured, it may be necessary to provide a valid username and password. The default password is 'anonymous'.

Zapmod

Zapmod compresses a module into a single '.zap' file.

Zapmod takes 2 arguments - the module to zap, and the name of the output file.

For example:
bmk zapmod mymods.testmod testmod.zap

UnzapMod

Unzapmod installs a module previously zapped with 'Zapmod'.

Unzapmod takes 1 argument - the module zap file to unzap. Note that any matching existing module will be overwritten by this operation.

For example:
bmk unzapmod testmod.zap