To simplify the execution of configure.pl, users may write a default arguments file or a Perl plug-in that provides default arguments. In either case, the idea is that arguments for Autoconf-generated configure scripts can be collected into reusable platform- and site-specified pieces so that they do not have to be passed every time configure.pl is run. The preferred method for specifying default arguments is the Perl plug-in, but for users who do not know Perl, a simple configuration file can be used instead. Here, we will only describe the process of loading these files, not how to use them.

To load the Perl plug-in, the arguments file is treated as loadable Perl code. (Indeed, the requirements of using the Perl plug-in state that it must be valid Perl code with a subroutine that can be called by another package.) Once the plug-in is loaded into memory, its subroutine is executed. The subroutine must return an array of command-line arguments that can be merged with @ARGV. It is the responsibility of the plug-in to inform configure.pl of its executable subroutine by assigning a subroutine reference to a global variable in configure.pl's scope. In configure.pl, this whole process involves roughly four lines of code, thus making it very attractive from the standpoint of maintaining configure.pl.

Loading the simple configuration file requires more effort because the file format must be parsed. In configure.pl, the parsing code for this file format is found in loadDefaultArgs(). To summarize the file format, platform-specific blocks are defined, and within a block, each line gives a configure script argument. The platform-specific blocks are named according to platform, though they can be named with user-defined identifiers when used in conjunction with the --os command-line option. Parsing the file simply means reading the right block(s) and adding each line to @ARGV.

Generating the reconfig helper script is quite simple. The arguments passed on the command line are simply saved to the reconfig file. In addition, commands to remove any Autoconf cache files (named config.cache) are added. Finally, the reconfig file is made executable.

This step is where configure.pl works the hardest. Ultimately, what must happen is that a given module's configure script is executed, and if it exits without failing, the execution environment of configure.pl is extended to reflect new information. This new information comes from the environment variable settings in the original configuration file. The details of how this works are a little bit more complicated, however.

The real goal of configure.pl is to run the configure script of the module the user wants to configure and build. Along the way, it may have to run configure scripts for one or more dependencies. Dependency information has already been covered in great detail, and we will not repeat it here. To ensure that the dependencies are configured in the correct order, the array of dependencies within the JugglerModule object is requested. Each dependency's configure script is run, and the execution environment is extended accordingly. The last dependency of a module is the actual module the user wants to configure and build. Once its configure script completes successfully, the top-level makefile can at last be generated.

The environment variables that are set reflect the delicate balance between configure.pl, configure.pl's configuration file, the *-config scripts, and the *.m4 files (see the section called “The *-config Scripts and the *.m4 Macro Files”). Based on the rules set forth by the *-config scripts and the *.m4 files, the execution environment must be set up so that each subsequent configure script can get information about any dependencies it has.

Generating the top-level makefile is relatively easy (it is mostly search-and-replace operations), but interestingly, this is one of the places where configure.pl falls short of acting like an Autoconf-based configure script. A template makefile (juggler/Makefile.in) is always the only file generated by configure.pl (aside from the reconfig script). There is no way to specify other files. Even if there were, configure.pl does not have easy access to the results of all the tests performed by the various configure scripts.

As a result of these limitations, there are only a few strings that can be expanded in the generated makefile. At this time, only two variables can be expanded: @JUGGLER_PROJECTS@ and @topdir@. The expansion of the first depends on the configured module and its dependencies; the expansion of the second is simply the directory where configure.pl was run.