build myapp @dbg --info

Normally, the utility will automatically create a Module Definition File for the linker. This will typically contain the EXETYPE command and any other commands as specified in any pragma() statements found in the source files. If you specify this switch, you will have to provide your own Module Definition File or its equivalent on the command line.

Sets verbose mode on for both Bud and for the compiler.

Set verbose mode on for just Bud and not for the compiler.

Normally, the utility will compile not only the files named in the command line, but also any file named in import statements if they require it. This switch will force the utility to only compile files named on the command line.

Example: Only compile the two files named

build fileone.d filetwo.d -explicit

By default, all the FINAL commands found in the configuration files are processed after successful compilation. You can control whether you want this or not by using this switch.

Example: Prevent processing of FINAL commands

-usefinal=no

Example: Ensure processing of FINAL commands (default)

-usefinal=yes

By default, if Bud comes across any empty arguments from either the commandline or configuration file, they are simply ignored. However by setting this switch to 'yes', you can force Bud to abort if it finds an empty argument.

Example: Abort on finding an empty argument

-emptyargs=no

Example: Ignore empty arguments (default)

-emptyargs=yes

Displays the names of the files used in building the target.

Normally, Bud scans the PATH environment symbol to find where the D compiler is located. However, if you need to use the compiler from a different location, you would use this switch to tell Bud where it is. Note: If you use this switch, and the current CFPATH value is identical to the current DCPATH value, then this switch will change both to the new value. The assumption is that the configuration file is in the same directory as the compiler. If this is not the case, you will also need to use the switch.

Example:

  -DCPATHc:\old\dmd\bin

Normally, Bud looks in the same place that the compiler is installed in, but if you need to use a different configuration path from that, you would use this switch to tell Bud where it is.

Example:

  -CFPATHc:\myproject\configs

Bud looks for configuration files in the following places...

Example:

  -BCFPATHc:\myproject\configs

Normally, Bud only compiles a source file if it's object file is out of date or missing. This switch forces all source files to be recompiled, even if not strictly required. Note: Module sources in the ignore list are still ignored though.

Normally, if Bud does not find a main() or WinMain() function in the source files, it creates a library to contain the object files. But when this switch is used, Bud will attempt to create an application by calling the linker rather than the librarian. You would typically use this if the main function was being supplied from an existing library or object file rather than one of your source files.

If the link is successful, this will cause the executable just created to run. You can give it run time arguments. Anything after the '-exec' will placed in the program's command line. You will need to quote any embedded spaces.

Example:

    -exec"abc.de second"

By default, the utility creates any work files in the same directory as the target file. You can use this switch to nominate an alternative location for these files. The directory is created if it doesn't exist.
 
For the DigitalMars compiler, this also specifies the top-level location where object files are created. By default, object files are created in the same directory as the corresponding source file.

Example:

        -odC:\temp\workarea

Normally, if Bud finds a main() or WinMain() function, it tries to create an application by calling the linker. If you use this switch however, the linker will not be called. You would typically do this if you wanted to create a library that stores your main function in it, in which case you'd also use the switch. But you could just create a set of object files without linking them with this switch.

Normally, if Bud finds a main() or WinMain() function, it tries to create an application by calling the linker. But if you use this switch, the librarian is called instead of the linker. You would typically do this if you wanted to create a library that stores your main function in it, in which case you'd also use the switch.

Normally Bud tries to create either an executable or a library file. However sometimes you just need the object files to be created. This switch is literally the same has if you had placed both -nolink and -nolib on the command line. As this is a common way to compile modules to just get their object files, without doing anything else, this neat shorthand is available.

Normally, if Bud does not find a main() or a WinMain() function, it calls the librarian to create a library for your object files. But if you use this switch, the librarian is not called.

Normally, Bud will only create a library using the object files that are in the same directory as the new library. You would use this switch if you wanted all object files created by this build session to be included in the library.

Normally, Bud does not delete any object files or working files when it finishes a session. You can use this switch to have Bud clean up after itself. This will remove all object files created in this run, plus any temporary work files.
 
Note: This can also be supplied as -clean as an alias.

This allows you to pass one or more command line arguments to the librarian.

Example: Set the page size to 32Kb

    -LIBOPT-p32

Example: Embedded spaces enclosed in quotes.

    "-LIBOPT -l -i"

This allows you to add one or more paths to be searched for library files.
 
This might be used when you don't want to permanently update the standard search paths.

Example:

    -LIBPATH=c:\mylibs;d:\3rdparty;c:\lib\debuglibs

For DigitalMars tools in the Windows environment, a response file is the default, but for other tools and other operating systems the default is to use command line arguments.
 
This switch has three formats:
 

 
The use of a response file is only really needed when the command line arguments are going to be more than the operating system can handle on a single command line. However, it is always a safe option, so if in doubt you may as well use it. A response file contains all the arguments that would have gone on the command line. They are arranged as one argument per line. Not all tools respect the response file idea however the Windows based DigitalMars tools do understand it.

This will display the command lines instead of running them. It can be used to see what would happen without actually building anything.

This is used to add a path that will be searched when Bud is looking for source files that are only supplied with relative paths.
 
The default source file search list is just the current directory. This switch adds a single path to that list. You can have any number of -PP switches on your command line. The utility scans through them in the order they appear as required.

Example:

build editor codeparser -PPc:\projects\myeditor\source

In the above example, Bud will look for 'editor.d' and 'codeparser.d' first in the current directory and then, if it didn't find them, in the folder 'c:\projects\myeditor\source'.

The default file is called default.rdf. But if you need to provide an alternate file, you can use this switch.

Example:

-RDFmyrules.xyz

The default file is called build.mdf. But if you need to provide an alternate file, you can use this switch.

Example:

-MDFmymacros.xyz

Note: This only applies to Windows environment.
 
Normally, if Bud finds a DllMain() function it automatically creates a DLL library. However, if you need to force a DLL library to be created instead of a normal library, you would use this switch.

Note: This only applies to Windows environment.
 
Normally, if Bud finds a WinMain() function it automatically creates a GUI application. However, if you need to force a GUI application, you would use this switch.
 
This switch can also be used to specify which version of Windows to build the application for. To do this, it takes the format of -gui:X.Y where X.Y is the Windows version number. Use 4.0 for Windows NT, 2000, and ME, and 5.0 for Windows XP.
 
By default, Bud uses the version of Windows it is running under.

Displays the version and path of the Bud application.

Example:

Path and Version : y:\util\build.exe v2.9(1197)
  built on Wed Aug 10 11:03:42 2005

This displays the commandline syntax, including all the switches, used to run Bud.
 
This has the aliases of -h and -?

Some messages are just informational and under some circumstances they can interfer with reading the output.

By default, for each source file that imports a module, it's path is added to the list of paths that will be searched for module source files. If you do not wish that behaviour, you will need to use this switch. In that case, the compiler will only search the paths specified in the compiler's configuration file, the current directory, and any explicitly added paths on the command line.

Example:

build myApp -noautoimport

Normally, Bud assumes that all imported modules are available to be recompiled if required. You would use this switch if you explictly did not want Bud to recompile a module. Note: The Phobos package of modules is automatically ignored. This means that Bud does not try to recompile phobos.

Example: ignore the module (or package) called 'parser'

-Xparser

You would use this to name any module that is not part of the target's dependancies, or is one of the ignored modules. You can use this switch to recompile phobos.

Example: (notice the Phobos package)

-Mphobos

Normally, Bud derives the target name from the first file name on the command line, or from the pragma(target) if present. If however, you wish to override that, use this switch. Note: This switch allows the use of a special token, {Target}, which is replaced by the default target name. You can use this form in a so that you can use it for building any application.

Example:

build editor -Ttestapp

In the example above, the executable built would be called (in Windows) 'testapp.exe' rather than the normal 'editor.exe'.

Example: Generate a name derived from the default name

build editor -Ttest_{Target}

In the example above, the executable built would be called (in Windows) 'test_editor.exe'.

By default, when creating a Windows GUI application, Bud will supply a list of commonly used windows libraries to the linker. However, if for some reason you do not want this to happen, you can use this switch to disable that.
 
Note: that this switch is not valid for Posix editions of Bud.

Use this switch to cause a Module List File to be created. This file will contain a list of all the module names processed by Bud. You can use the Configuration File to specify the layout of this file, but by default the file will look like a Ddoc macro definition ...

   MODULES =
     $(MODULE mod1)
     $(MODULE mod2)
     ...
   

The name of the Module List File will be as specified on the switch, but if not supplied it takes the form of <target>_modules.ddoc .

This causes Bud to create a file that details the modules that are used by a module and the modules that uses a module.
 
You can optionally specify a name for the cross reference file. If you don't then the name of the cross reference file takes the Target file's base name and adds the extension ".use".
 
The file is in two sections. The first, headed by the line "[USES]" lists each file that has been analyzed. Each line has the file name followed by "<>" followed by the path of a module that the file uses. The second, headed by the line "[USEDBY]" lists each module that has been used. Each line has the module followed by "<>" followed by the name of the file that uses it.
 
Each section is sorted in ascending order.

Example: The layout of the cross reference file

build tres -uses=xref.txt
type xref.txt
[USES]
bar.d <> y:\dmd\src\phobos\std\stdio.d
foo.d <> bar.d
tres.d <> foo.d
tres.d <> tres_bn.d
tres.d <> y:\dmd\src\phobos\std\stdio.d
[USEDBY]
bar.d <> foo.d
foo.d <> tres.d
tres_bn.d <> tres.d
y:\dmd\src\phobos\std\stdio.d <> bar.d
y:\dmd\src\phobos\std\stdio.d <> tres.d

For DMD environments, Bud expects that object files will be created in the same directory as the source file, or in the directory specified in any -od switch. However, this switch can tell Bud to expect them in the current directory.
 
For GDC environments, Bud expects that object files will be created in the current directory. However this switch can tell Bud to expect then to be in same directory as the source file, or in the directory specified in any -od switch.
 
The forms -UMB, -UMB=Yes, -UMB:Yes, -UMB=Y, -UMB:Y, -UMB=, -UMB: all mean the same; that the object files are expected in the current directory. Any other form of the switch (eg. -UMB=No ) will make the utility expect the object files to be in the same directory as the source files.
 
Unless you have some special need to do this, the -UMB switch is not really required.
 

Example:

build editor -UMB=Yes

In the example above, the utility will expect object files to be created in the current directory.