The configuration is the step in which a build system detects the availability of some tool and creates the parameters that will be used during the compilation of the program. The configuration is twofold: use the options that are given by the end-user (command-line options, environment) and use the configuration routines given by the main developer.
In practice, the configuration routines cannot be launched until the command-line is parsed entirely. There is then an need to provide the build system with the options before it starts running the configuration tests.
Though developers spend most of their time on a single app at a time, build masters like to automate the builds. Many programs are then grouped together in packages which can be compiled either as a whole, or as individual packages. This means that the configuration options and routines must be searched in recursively in the build system scripts.
Scons scripts are actually python scripts, and this makes it very easy to add conditions or loops to change the target properties. The script code is often lengthy, and it is a bad idea to let it go into functions due to the amount of indentation to add.
The installation must also be handled from the same scripts, as it is difficult to insulate the build code from the installation code. It is also mandatory to read the scripts only once.
All three solutions have been tried within Waf. The first solution has lead to scripts containing areas that the python interpreter could not see until very late, making debugging difficult. What is more, there was no more syntax highlighting and the code became very ugly.
The second scheme (sconfigure) was not satisfactory as it introduced one more file type (there was already sconstruct and sconfigure). It also did not solve the problem of the configuration tests that need to be processed only after the command-line options.
The third scheme did not only solve the problems listed above, but also made it possible to eliminate the artificial distinction between sconstruct and sconscript. The existing script types have been eliminated to a new type (wscript) in which only variable and function declarations are allowed (real python modules). When a wscript is imported (python module), the functions contained in it are stored and used when needed. This scheme is much more pythonic, and makes it really easy to collect the options before running the configuration without having different file types.
In the case of one function (build) becoming too huge, it is possible to make a script to replace the content of such a function. For example, a script named wscript_build can be provided to replace the call to the module function "build".
The following script illustrates the concepts described above. This script is actually a python module containing special functions: set_options, configure, build. These functions are imported once and then called in a particular order at runtime.