An instance of the class _waflib.Context.Context_ is used by default for the custom commands. To provide a custom context object it is necessary to create a context subclass:
// advbuild_subclass
[source,python]
---------------
def configure(ctx):
print(type(ctx))
def foo(ctx): <1>
print(type(ctx))
def bar(ctx):
print(type(ctx))
from waflib.Context import Context
class one(Context):
cmd = 'foo' <2>
class two(Context):
cmd = 'tak' <3>
fun = 'bar'
---------------
<1> A custom command using the default context
<2> Bind a context class to the command _foo_
<3> Declare a new command named _tak_, but set it to call the script function _bar_
The execution output will be:
[source,shishell]
---------------
$ waf configure foo bar tak
Setting top to : /tmp/advbuild_subclass
Setting out to : /tmp/advbuild_subclass/build
<class 'waflib.Configure.ConfigurationContext'>
'configure' finished successfully (0.008s)
<class 'wscript.one'>
'foo' finished successfully (0.001s)
<class 'waflib.Context.Context'>
'bar' finished successfully (0.001s)
<class 'wscript.two'>
'tak' finished successfully (0.001s)
---------------
A typical application of custom context is subclassing the build context to use the configuration data loaded in *ctx.env*:
This technique is useful for writing testcases. By executing 'waf test', the following script will configure a project, create source files in the source directory, build a program, modify the sources, and rebuild the program. In this case, the program must be rebuilt because a header (implicit dependency) has changed.
When the top-level wscript is read, it is converted into a python module and kept in memory. Commands may be added dynamically by injecting the desired function into that module. We will now show how to bind a simple command from a Waf tool:
Waf tools are loaded once for the configuration and for the build. To ensure that the tool is always enabled, it is mandatory to load its options, even if the tool does not actually provide options. Our tool 'some_tool.py', located next to the 'wscript' file, will contain the following code:
The _WAFLOCK_ environment variable is used to control the configuration lock and to point at the default build directory. Observe the results on the following project:
<1> The lock file points at the configuration of the project in use and at the build directory to use
<2> The files are output in the build directory +debug+
<3> The configuration _release_ is used with a different lock file and a different build directory.
<4> The contents of the project directory contain the two lock files and the two build folders.
The lock file may also be changed from the code by changing the appropriate variable in the waf scripts:
[source,python]
---------------
from waflib import Options
Options.lockfile = '.lock-wafname'
---------------
NOTE: The output directory pointed at by the waf lock file only has effect when not given in the waf script
==== Changing the output directory
===== Variant builds
In the previous section, two different configurations were used for similar builds. We will now show how to inherit the same configuration by two different builds, and how to output the targets in different folders. Let's start with the project file:
